After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 543148 - native file monitoring for os x
native file monitoring for os x
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gio
unspecified
Other Mac OS
: Normal enhancement
: ---
Assigned To: Alexander Larsson
gtkdev
Depends on:
Blocks:
 
 
Reported: 2008-07-15 18:32 UTC by Matthias Clasen
Modified: 2015-08-21 03:22 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Matthias Clasen 2008-07-15 18:32:11 UTC
OS X must have some native file monitoring api that we should use to avoid the poll file monitor. las almost had a heart attack when he discovered threads being created to handle the poll timeout...
Comment 1 Richard Hult 2008-07-15 19:02:22 UTC
If someone wans to implement it, take a look at  onlhttp://developer.apple.com/documentation/Darwin/Reference/FSEvents_Ref/FSEvents/CompositePage.html

Only available for 10.5+ though.

Comment 2 Erik van Pienbroek 2008-08-20 22:52:24 UTC
Matthias, you were talking about a 'poll file monitor'. Is this still used somewhere? With glib 2.17.7, every time I try to create a GFileMonitor I receive the error 'Unable to find default local directory monitor type'. Is there some way to work around this for now or is native support for file/directory monitoring really required?

Richard, is there any specific reason why you advise the FSEvents API (and thus limiting such functionality to OS X 10.5+ users) ? I've seen OS X also supports BSD's kqueue and kevent functions, which works on OS X 10.4+ and offers all the functionality needed for the GFileMonitor to monitor files and directories
Comment 3 Richard Hult 2008-08-21 07:55:02 UTC
Erik, I simply didn't know about it :)

Comment 4 Daniel Macks 2008-12-01 22:25:07 UTC
kqueue maybe? It's what poll() uses internally, which sucks precisely because each call sets up a whole new kqueue monitor to test. If gio wants to do long-term/repeated test, could set up its own kqueue once and watch it.
Comment 5 Matthias Clasen 2015-08-21 03:22:56 UTC
We have a kqueue file monitor implementation now