GNU bug report logs - #22534
File notify broken on Windows

Previous Next

Full log

View this message in rfc822 format

From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22534 <at> debbugs.gnu.org, Michael Albinus <michael.albinus <at> gmx.de>
Subject: bug#22534: File notify broken on Windows
Date: Fri, 5 Feb 2016 16:34:17 +0100

[Message part 1 (text/plain, inline)]

2016-02-05 11:10 GMT+01:00 Eli Zaretskii <eliz <at> gnu.org>:

> > From: Fabrice Popineau <fabrice.popineau <at> gmail.com>
> > Date: Fri, 5 Feb 2016 06:59:00 +0100
> > Cc: Michael Albinus <michael.albinus <at> gmx.de>, 22534 <at> debbugs.gnu.org
> >
>
> >  > Once the limit is reached, only the first notification is returned.
> >
> >  What do you mean by "the first notification"? AFAIU, the 1000 events
> >  are generated as 500 pairs of renames, so what is "the first" here,
> >  after 260 were already generated?
> >
> > The notification for the first pair in the list, the one numbered 999 is
> the only one
> > appearing in file-notify--test-events.
>
> So you are saying that as soon as the value of n is greater than some
> threshold, like 260, the test reports only the first pair of renames,
> is that true?
>
>
Yes, this is what I observe with different values of n.



> If so, did you try to insert waits in-between the series or renames?
>

I have tried to add a sit-for in the loop which renames the files, but
it does not help.


> Or maybe the preceding series of file creations is the culprit, and we
> should give Emacs more time to report them?
>

I have tried with different values of file-notify--test-timeout but it
doesn't seem
to make any difference. I also boosted the size of the file_notifications[]
array (* 16)
without any difference. I have tested with sit-for between each rename
operation
and it does not work either above 260 files



Because right now, it just fires up all of them in a single quick
> series.
>
> Hmm... actually, I might see a problem.  If my reading of the test is
> correct, it first creates 2000 files, and then issues 1000 renames,
> which on Windows generate 2000 notifications.  Together, these add up
> to 4000, which is awfully close to the 4096 size of the Emacs input
> event queue.  So maybe the test fills up the event queue, and the
> synchronization between the w32notify thread and the main thread stops
> working at that point?  Or maybe we are hitting on some limit of
> Windows messages that can be enqueued?
>
>
I would have expected some Win32 function to error at some point ?

Also, would it be useful to use the overlap mechanism ? Would it help to
overcome this kind of limitation ?


> (To tell the truth, I'm not sure what is the purpose of that test:
> AFAIK, none of the available notification back-ends ever promised not
> to lose events, so what are we testing here?  Perhaps Michael can
> explain.)
>
> >  I've just found a serious problem, see bug#22557. I'm not sure it is
> >  related to what you see here, but IMO until that bug is resolved,
> >  there's no sense in trying to analyze what happens with notifications
> >  on MS-Windows.
> >
> > Ok, I have seen that. Maybe I'll try to comment out the part of the
> patch you have pointed out in this bug report
> > and see how it changes the behavior.
>
> If you have time, yes, please.
>
>
It does not help with file-notify-test06-many-events but I would have
expected it.


> Btw, are you doing this on master or on emacs-25?  The files involved
> seem to be identical for now, but they might diverge in the future.
>

emacs-25 at this time.

Fabrice

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.