Re: gfile-based file notifications are not immediate

[Eli Zaretskii]

> From: Dima Kogan <address@hidden>
> Date: Sat, 25 Oct 2014 13:17:29 -0700
> 
> As in the inotify thread, I set up a simple test. I built emacs using
> 
>  ./configure --with-file-notification=inotify
> 
> I then ran
> 
>  ./emacs --eval "`cat  /tmp/tstnotify.el`" -Q -nw
> 
> with tstnotify.el being
> 
>  (progn
>    (require 'filenotify)
> 
>    (dolist (fil '("/tmp/tst1" "/tmp/tst2"))
>      (file-notify-add-watch fil  '(change attribute-change)
>                             (lambda (event)
>                               (message "notify event %s" event)))
>      (find-file fil))
>    (switch-to-buffer "*Messages*"))
> 
> 
> Here I ask for notifications for two files, and print out the events as
> they come in. While emacs is running this way, I modify those two files
> using an external tool. I would expect to see modification events for
> both of these files, as soon as these modifications happen. Instead, the
> notifications come in either 30 seconds later, or whenever anything goes
> through emacs's input queue. So the notification is greatly delayed if
> the user is not touching their emacs.
> 
> The reason is that when emacs is idle, it's blocking in the pselect()
> call in xg_select() in process.c. pselect() is an operating-system call,
> not a glib one. Later on in xg_select() there's some code to kick the
> glib event loop, but as long as we're sitting in the pselect(), that
> secondary event loop remains untouched.

Maybe I'm confused, but are you saying that even though you
specifically requested for inotify notifications, and even though the
configure script shows

  Does Emacs use a file notification library?       yes -lglibc (inotify)

when it finishes, Emacs still uses glib file notifications, and the
functions in inotify.c are never called?

When functions in inotify.c are called, they add a file descriptor to
the set monitored by pselect (see the call to add_read_fd in
inotofy.c), so we shouldn't be waiting for glib event loop, I think.

Oh, maybe this all happens because ytour build is with GTK, and
therefore HAVE_GLIB is defined, so we call xg_select instead (I think
because some unwanted interference between these two mechanisms).  So
perhaps try building without GTK (or any other optional features that
pull in glib).