bug#22534: File notify broken on Windows

[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
> 
>  Support for file notifications in batch mode is fragile: w32notify
>  normally works by sending a message to the main thread whenever it has
>  a notification to report. But in batch mode, the main thread doesn't
>  read Windows messages, so whether an event gets reported depends on
>  whether 'pselect' is called, which depends on what API is called to
>  wait for notifications and read them.
> 
> Ok. Maybe that's the reason, but in this case, the expected events have to be adjusted because 'make check'
> runs in batch mode.

True.  I have done that several times to fix that test; maybe it's
time to do that again.

>  > 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?

If so, did you try to insert waits in-between the series or renames?
Or maybe the preceding series of file creations is the culprit, and we
should give Emacs more time to report them?
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?

(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.

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.

Thanks.