Thinner binding to the Linux Kernel's inotify interface
|Latest on Hackage:||0.3.0.1|
This package is not currently in any snapshots. If you're interested in using it, we recommend adding it to Stackage Nightly. Doing so will make builds more reliable, and allow stackage.org to host generated Haddocks.
This is a binding for GHC 7 to the Linux Kernel's inotify interface, which provides notifications to applications regarding file system events, such as file creation, modification, deletion, etc.
Some of the advantages over hinotify are:
linux-inotify provides a plain getEvent operator that blocks, instead of implementing a callback API.
linux-inotify avoids most of GHC's standard IO handling code, relying on plain system calls with minimal overhead in Haskell-land. (However, it still does make good use of GHC's IO manager via nonblocking inotify sockets and threadWaitRead, so getEvent is still efficient.)
linux-inotify does not call forkIO, which means less context switching and scheduling overhead, especially in contexts where hinotify's particular event router isn't a very good fit for your application; e.g. you are implementing a following log file processor.
Some of the disadvantages compared to hinotify are:
Due to the use of
linux-inotifycurrently requires linux 2.6.27 or later, even though
inotifysupport debuted in linux 2.6.13. You can check which version of linux is on a machine via
-a. I would like to fix this at some point, but it isn't a personal priority.
linux-inotifyrequires GHC 7.8.1 or later, whereas
hinotifyworks with many versions of GHC 6. I have no plans to fix this.
Version 0.3.0.1: (2015-11-20)
peekEventNonBlocking now raise an
IOException when they are called on an inotify descriptor that
has been closed and have an empty buffer, instead of returning
Nothing. This is more in line with the behavior of other IO
functions such as
Attempted to improve documentation.
Version 0.3.0.0: (2015-11-20) * Use-after-close now result in exceptions rather than undefined behavior.
All functions are now (intended to be) thread-safe.
Masked async exceptions during a buffer fill, which could otherwise have resulted in losing an entire buffer of events. In particularly unlucky cases, it might have been possible that futher use of the buffer could have resulted in memory faults.
Masked async exceptions when closing a descriptor, which could otherwise have resulted in leaking an inotify file descriptor.