bug#22534: File notify broken on Windows

[Fabrice Popineau <fabrice.popineau@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3172 bytes --]

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

> > From: Fabrice Popineau <fabrice.popineau@gmail.com>
> > Date: Fri, 5 Feb 2016 06:59:00 +0100
> > Cc: Michael Albinus <michael.albinus@gmx.de>, 22534@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

[-- Attachment #2: Type: text/html, Size: 5245 bytes --]