Re: File monitor rewrite: Solaris (and other) help wanted

Hash: SHA1

On 14/01/15 23:00, Ryan Lortie wrote:
I'm making substantial modifications to the file monitoring system in
GIO.  I've gotten to the point where I feel comfortable pushing a branch
that contains the main ideas:

It's not even vaguely tested or stable and will probably crash under
anything more than the most trivial of uses.  Work will continue over
the next days.

The private API between GIO and the internal file monitor backends has
changed substantially.  See the commit message for details about that. 
This means that all of the backends will need non-trivial changes.  I've
already made the required modifications to the inotify backend.  I plan
to move next to the kqueue backend and I could probably even tackle the
FAM and win32 backends myself.

I have no means of testing changes to the 'fen' backend (Solaris).

It would be awesome if someone with a Solaris box and some free time
could port the fen backend to the new changes.  If nobody comes forward,
we will probably remove the backend.

I might be a bit offtopic, but I saw "file monitor rewrite" and I had to
jump in...

Currently GFileMonitor doesn't have a unique way to know whether a file
got closed. There is the changes-done-hint event, but that covers IIRC 2
things: files getting closed and also a "virtual" emission which happens
after some time even if the files were not closed (think of a log file
which never gets closed). The main issue is that if you want to get
notified of when a file was fully updated *and* closed, you need to
fallback to raw inotify. The rationale for wanting to get notified only
when the file got closed is e.g. Tracker monitoring the Downloads/
directory. We may not want to extract file info for an ongoing download,
just for when the download is fully finished (and destination file
closed). More background here:

alexl noted that non-Linux systems may not have support to notify files
closed, so removing the changes-done-hint virtual emission wasn't an
option in GLib. Still, I think that the original (obsoleted) patch in
that bugreport (which allows to at least disable the virtual emission
via a property) may be useful for Linux/inotify users. For other
backends we could just ignore the disabling possibility...

- -- 
Version: GnuPG v2


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]