Hi. I was looking into an issue in emacs, where file notifications that use gio would not fire without any user input in emacs. This turned out to be a bug in glib that pops up if you use file notifications with your own event loop, which is what emacs does.

Emacs does not call gtk_main(), but instead retrieves a list of active file descriptors with g_main_context_query(), and then uses pselect() to wait on those file descriptors and others.

The issue is that the file descriptors returned by g_main_context_query() are not given data by the notification system, so using select() on them does nothing.

I'm attaching a sample program that demonstrates this issue. It registers a file monitor on /tmp/dat, and runs a main loop in the way emacs does, as described above. When a notification event fires, this program prints something. The select() call has a timeout of 5 seconds. After select() returns, I process the glib events. So as glib stands now, select() doesn't work right so glib notification events are always delayed until the next time select() times out: 5 seconds in this case.

This can be fixed by kicking the main loop. For instance, I can call

  g_main_context_wakeup(NULL);

right after the g_file_monitor_emit_event() call in ih_event_callback() in inotify-helper.c. This isn't the right solution, since it assumes inotify, but something like this should be done.

After I make that change, the select() actually works in my test program. There is still a 1 second delay between when the OS tells glib about the modification (ik_read_callback() call) and when the main loop gets the event, but that's a different bug, I suspect.