[Top][All Lists]

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

Re: gfile-based file notifications are not immediate

From: Dima Kogan
Subject: Re: gfile-based file notifications are not immediate
Date: Thu, 30 Oct 2014 12:39:55 -0700

Perry E. Metzger <address@hidden> writes:

> On Thu, 30 Oct 2014 19:11:55 +0100 Michael Albinus
> <address@hidden> wrote:
>> Stefan Monnier <address@hidden> writes:
>> >> If people on BSD/OS X do not want to use glib, somebody shall
>> >> write kqueue support. But it is said to be a hassle,
>> >
>> > .. and a waste of time since glib already does it for us,
>> I agree with you. But *if* somebody writes native kqueue support,
>> because he doesn't want to touch glib on OS X: would you as Emacs
>> maintainer reject this contribution?
> I've been reading the actual code. So far, I'm not sure
> how glib could be conveniently used here on Mac OS X even if one
> wanted to. From what I can tell, the glib code seems to depend on the
> central event loop being managed by glib/gtk, which is not the case
> on a port that uses a different GUI. There are also different select
> replacements (ns_select vs xg_select etc) used on the different
> platforms because they have differing event loop handling.
> I might be mistaken, though. I've never read any of the low level
> event handling code before and I'm still a bit fuzzy on all the
> details.

Look at xg_select.c. You call g_main_context_query() to retrieve a list
of file descriptors, and then you use pselect() on those AND on other
file descriptors emacs cares about. So even on my Debian machine the
event loop is still handled by emacs.

And please note that the whole reason I started this whole kerfuffle was
to get rid of delays in auto-revert-mode, and inotify is way closer to
getting us there than glib is:


So please do not get rid of the inotify stuff yet.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]