Re: Using glib's g_file_monitor_file and g_file_monitor_directory

[Eli Zaretskii <eliz@gnu.org>]

> Date: Tue, 28 May 2013 09:52:31 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> On 05/28/13 09:43, Eli Zaretskii wrote:
> > So you are asking whether it would make sense to replace use of
> > 'select' for process notifications by events that are put on the
> > keyboard queue?
> 
> Something like that, yes.  It wouldn't be a keyboard queue,
> so much as a unified event queue.  Currently Emacs's low
> level is confusing, since it's getting notifications
> via signals and via reads.  It'd be nicer if there was just
> one way to get notified, and if most of the low-level code
> didn't have to worry about being interrupted by signal handlers.

But this eventually boils down to the mechanisms supported by the OS
for each kind of events, doesn't it?  E.g., we could use glib or
whatever for converting process notifications into readable events,
but if that library uses signals internally, our code still can be
interrupted by signals, right?