|Subject:||bug#22534: File notify broken on Windows|
|Date:||Fri, 5 Feb 2016 16:34:17 +0100|
> From: Fabrice Popineau <address@hidden>
> Date: Fri, 5 Feb 2016 06:59:00 +0100
> Cc: Michael Albinus <address@hidden>, address@hidden
> > 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
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
> 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.
|[Prev in Thread]||Current Thread||[Next in Thread]|