From: Dima Kogan <dima@secretsauce.net>
To: 18861@debbugs.gnu.org
Subject: bug#18861: 25.0.50; gfile-based file notifications are not immediate
Date: Mon, 27 Oct 2014 17:29:16 -0700 [thread overview]
Message-ID: <87zjchdokj.fsf@secretsauce.net> (raw)
This is a bug-tracker entry for this mailing list post:
http://lists.gnu.org/archive/html/emacs-devel/2014-10/msg00941.html
Contents of the post:
In the last few days I started several threads about various details of
file notification and auto-revert behavior. This one is about some
incorrect behavior of notifications using the 'gfile' (gio from glib)
backend.
As in the inotify thread, I set up a simple test. I built emacs using
./configure --with-file-notification=gfile
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.
Even if you kick the event loop in time, the notification is still
delayed a few seconds (I verified this with some test code, outside of
emacs; can post if anybody wants it). THIS is a separate issue that is
likely a bug in glib. On Linux it uses inotify internally, so if one was
using Linux, would there be any reason to use this notification scheme
instead of using inotify directly? Are there OSs where emacs supports
notifications ONLY through glib?
next reply other threads:[~2014-10-28 0:29 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-28 0:29 Dima Kogan [this message]
[not found] ` <handler.18861.B.14144561857404.ack@debbugs.gnu.org>
2014-10-28 4:22 ` bug#18861: Acknowledgement (25.0.50; gfile-based file notifications are not immediate) Dima Kogan
2014-10-28 21:30 ` Dima Kogan
2014-10-30 16:12 ` Stefan Monnier
2014-11-05 19:19 ` Dima Kogan
2014-11-06 3:02 ` Stefan Monnier
2014-11-06 8:37 ` Michael Albinus
2014-11-06 18:26 ` Dima Kogan
2014-11-06 23:35 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zjchdokj.fsf@secretsauce.net \
--to=dima@secretsauce.net \
--cc=18861@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.