From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#22534: File notify broken on Windows Date: Fri, 05 Feb 2016 12:10:19 +0200 Message-ID: <83fux7v56c.fsf@gnu.org> References: <83h9hrytom.fsf@gnu.org> <87lh72xln0.fsf@gmx.de> <838u30wbx5.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1454667096 15408 80.91.229.3 (5 Feb 2016 10:11:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Feb 2016 10:11:36 +0000 (UTC) Cc: 22534@debbugs.gnu.org, michael.albinus@gmx.de To: Fabrice Popineau Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Feb 05 11:11:25 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aRdME-00088J-A5 for geb-bug-gnu-emacs@m.gmane.org; Fri, 05 Feb 2016 11:11:18 +0100 Original-Received: from localhost ([::1]:47261 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRdMA-00035v-1G for geb-bug-gnu-emacs@m.gmane.org; Fri, 05 Feb 2016 05:11:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35346) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRdM3-000342-38 for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2016 05:11:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRdLy-0001Jw-Fc for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2016 05:11:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52474) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRdLy-0001Jq-Ca for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2016 05:11:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aRdLy-0005mE-6N for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2016 05:11:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Feb 2016 10:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22534 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22534-submit@debbugs.gnu.org id=B22534.145466704022175 (code B ref 22534); Fri, 05 Feb 2016 10:11:02 +0000 Original-Received: (at 22534) by debbugs.gnu.org; 5 Feb 2016 10:10:40 +0000 Original-Received: from localhost ([127.0.0.1]:32830 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRdLc-0005lb-7p for submit@debbugs.gnu.org; Fri, 05 Feb 2016 05:10:40 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:44294) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRdLa-0005lO-BF for 22534@debbugs.gnu.org; Fri, 05 Feb 2016 05:10:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRdLQ-0001HF-AJ for 22534@debbugs.gnu.org; Fri, 05 Feb 2016 05:10:32 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45941) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRdLQ-0001HB-6j; Fri, 05 Feb 2016 05:10:28 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1404 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aRdLP-0003xx-3N; Fri, 05 Feb 2016 05:10:27 -0500 In-reply-to: (message from Fabrice Popineau on Fri, 5 Feb 2016 06:59:00 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:112483 Archived-At: > From: Fabrice Popineau > Date: Fri, 5 Feb 2016 06:59:00 +0100 > Cc: Michael Albinus , 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.