emacs-bug-tracker
[Top][All Lists]
Advanced

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

[debbugs-tracker] bug#18861: closed (25.0.50; gfile-based file notificat


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#18861: closed (25.0.50; gfile-based file notifications are not immediate)
Date: Thu, 06 Nov 2014 03:04:01 +0000

Your message dated Wed, 05 Nov 2014 22:02:57 -0500
with message-id <address@hidden>
and subject line Re: bug#18861: Acknowledgement (25.0.50; gfile-based file 
notifications are not immediate)
has caused the debbugs.gnu.org bug report #18861,
regarding 25.0.50; gfile-based file notifications are not immediate
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
18861: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18861
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 25.0.50; gfile-based file notifications are not immediate Date: Mon, 27 Oct 2014 17:29:16 -0700
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?



--- End Message ---
--- Begin Message --- Subject: Re: bug#18861: Acknowledgement (25.0.50; gfile-based file notifications are not immediate) Date: Wed, 05 Nov 2014 22:02:57 -0500 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
Thanks Dima,

Seeing as noone made any comment, I just installed your patch (with minor
tweaks) and hope it does the right thing.


        Stefan


> +  if (g_main_context_acquire(context))
                              ^^
Missing space before paren.

> +  n_gfds = context_acquired ?
> +      g_main_context_query (context, G_PRIORITY_LOW, &tmo_in_millisec,
> +                            gfds, gfds_size) :
> +      -1;

The GNU coding style recommends to break lines before rather than after
operators.

> +    g_main_context_release(context);
                            ^^
Same.


--- End Message ---

reply via email to

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