bug#22534: File notify broken on Windows

[Fabrice Popineau]

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