Thinner binding to the Linux Kernel's inotify interface

Latest on Hackage:

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 to host generated Haddocks.

BSD3 licensed by Leon P Smith

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:

  1. linux-inotify provides a plain getEvent operator that blocks, instead of implementing a callback API.

  2. 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.)

  3. 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:

  1. Due to the use of inotify_init1, linux-inotify currently requires linux 2.6.27 or later, even though inotify support debuted in linux 2.6.13. You can check which version of linux is on a machine via uname -a. I would like to fix this at some point, but it isn't a personal priority.

  2. linux-inotify requires GHC 7.8.1 or later, whereas hinotify works with many versions of GHC 6. I have no plans to fix this.


Version (2015-11-20) * getEventNonBlocking and 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 Data.ByteString.hGetNonBlocking.

  • Attempted to improve documentation.

Version (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.

Depends on 4 packages:
Used by 1 package:
comments powered byDisqus