Re: [PATCH] Added basic file system watching support.

[Rüdiger Sonderfeld]

Thank you for your reply!

On Friday 28 September 2012 10:13:52 you wrote:
> I'm not very familiar with inotify and other file-system watching
> facilities, so just as a guideline for others's reviews: I'm OK with
> installing in 24.3 a non-complete version of the code, and I'm OK to
> install before the freeze a code that needs more testing, *but* only if
> those missing functionalities and testing won't require a redesign of
> the API.

It could require a minor redesign of the API.  At least I want to gather some 
experience using the API first.  And maybe porting it to other systems will 
require API adjustments.  Both BSD's and Windows' filesystem watch APIs are 
not as powerful as inotify.

> I understand that NAME refers to the added/removed file, but I'm
> wondering why we don't also add FILENAME (the name of the directory) to
> the event.  If inotify doesn't provide it, we can provide it
> ourselves, right?
> Or is it rarely/never needed?
> Or is it because that directory may change name without us knowing?

The name might change.  This would require file-watch to register MOVE_SELF 
events for every watched file and then update the name.  This would make the 
code quite complicated and worst of all leave the user wondering why the name 
suddenly changed unless we force him to always accept MOVE_SELF events.  Which 
would then again impose something on the user he might not need.  Therefore I 
think it is better if the user keeps track of any ID to FILENAME mapping 
himself.  Maybe there could be some user defined storage in the ID to handle 
it.

> I can't remember enough of the context, but objects that are "unique"
> are plentiful.  A cons cell would do, regardless of its value, for
> example (now, as to whether it's better than a number, that depends on
> what it's use for, e.g. whether you can put the cons's fields to good
> use).

Currently the only risk is that cookie is bigger than MOST_POSITIVE_FIXNUM and 
then gets mapped to a value that is already taken by another cookie.  This is 
only a problem on 32bit systems without the use of wide-int because cookie is 
uint32_t.

There is a similar problem with the watch descriptor.  It is currently also 
stored in the ID with make_number.  Inotify uses an incremental system for 
watch descriptors and should be run out of descriptors by the time 
MOST_POSITIVE_FIXNUM is reached.  But there is no guarantee for it.  Therefore 
something like SAVE_VALUE should probably be used.

Regards
Rüdiger