Re: [PATCH updated] Support for filesystem watching (inotify)

[Ted Zlatanov <tzz@lifelogs.com>]

On Tue, 07 Jun 2011 11:42:40 -0300 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>>>> The problem is: How to implement the file-unwatch then? I need a way
>>>> to identify each separate file-watch request.  What would be the best
>>>> way to do that?

SM> How about letting file-watch return a "file-watcher" which you then need
SM> to pass to file-unwatch?  This "file-watcher" could be any kind of Elisp
SM> data you find convenient for this.  You may decide to provide no other
SM> operation than file-unwatch, but you could also decide to provided
SM> additional operations such as changing the callback (I'm not saying
SM> that would necessarily be a good idea, tho, but maybe other operations
SM> would be handy).

>> (background: url-future.el is really a generic futures library, but the
>> only expected use for it currently is in url-*.el)

>> The "file-watcher" could derive from url-future, with the nice
>> error-catching and accessor functions that come with it, plus it's
>> protected from double-invocation.

SM> That doesn't sound right to me.  At least I'm having trouble figuring
SM> out how to bend my mind such that this file-watcher matches (even
SM> coarsely) the concept of a "future".

In this case it's just a place to stash the callback, with protection
against double invocation and error catching.  Each instance holds a
separate `file-watch' request.

`file-unwatch' simply invokes the lambda to get the value to deregister.

So `file-watch' would return

(make-url-future :value (lambda () (unwatch file here))
                 :errorback  (lambda (&rest d) (handle unwatch errors))
                 :callback (lambda (f) (arbitrary callback)))

Which, in turn, can be used (say it's saved in `f'):

(url-future-call f) ; funcall :value
(url-future-value good) ; whatever (unwatch file here) returned
(url-future-done-p f) ; true
(url-future-completed-p f) ; true if no errors, plus :callback was called
(url-future-errored-p f) ; true if errors, plus :errorback was called

(url-future-call f) ; throws an error

I think that's more convenient than a new special "file-watcher" type,
especially since the "file-watcher" can be derived from "url-future" and
inherit all the functions above under its own namespace, plus of course
any fields it cares to define on top.  The built-in support for
callbacks and error callbacks is pretty nice too.

Ted