Factor Language Blog

So I mentioned a few days ago that I had a file system change monitor API going on Windows. Now I’ve implemented a Linux backend and will be looking at Mac OS X next.

The API is straightforward. First, you create a monitor, passing it a directory and whether the monitor should recurse to subdirectories or not – non-recursive monitors are supported on Windows, but on Linux all monitors are recursive;

"/home/slava/factor/" t <monitor>

Monitors must be disposed by using dispose or with-disposal since they wrap operating system resources. They function essentially as streams; you read from a monitor, which blocks until some file in the directory has changed. The file’s path name is returned along with an array of descriptors indicating what has changed:

dup next-change . .

A sample piece of output might be:

{ +modified-file+ }
"/home/slava/factor/test.txt"

That is all! If you need to continuously monitor a directory for changes, all you have to do is spawn a new thread with in-thread, then call next-change in a loop and take appropriate action.

On Linux and Windows, we use asynchronous notifications behind the hood, so the block API presented to the user is actually implemented with continuations and a low-level multiplexer behind the scenes, just like all non-blocking I/O in Factor.

I’m going to use the io.monitor API to speed up the vocabulary browser and refresh-all. Right now they have to scan the whole Factor source tree but instead they will monitor it for changes. Since not all OSes support change notification, and not all file systems on supported OSes support it either, there will be graceful fallbacks, of course.

I’m not aware of any other language which attempts to implement advanced I/O functionality in a cross-platform manner. Java’s process launcher is limited compared to io.launcher, and it doesn’t support a cross-platform file system notification API at all; Python, Ruby and Perl implement advanced features but present OS-specific APIs to the programmer. Furthermore Factor attempts to integrate as much as possible with the I/O event loop, and of course, everything is consistently documented.