From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Fabrice Popineau Newsgroups: gmane.emacs.bugs Subject: bug#22534: File notify broken on Windows Date: Fri, 5 Feb 2016 16:34:17 +0100 Message-ID: References: <83h9hrytom.fsf@gnu.org> <87lh72xln0.fsf@gmx.de> <838u30wbx5.fsf@gnu.org> <83fux7v56c.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0160b7c6be9a43052b079638 X-Trace: ger.gmane.org 1454686529 14081 80.91.229.3 (5 Feb 2016 15:35:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Feb 2016 15:35:29 +0000 (UTC) Cc: 22534@debbugs.gnu.org, Michael Albinus To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Feb 05 16:35:19 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 1aRiPk-0003Ws-Oc for geb-bug-gnu-emacs@m.gmane.org; Fri, 05 Feb 2016 16:35:17 +0100 Original-Received: from localhost ([::1]:48936 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRiPk-00039I-09 for geb-bug-gnu-emacs@m.gmane.org; Fri, 05 Feb 2016 10:35:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54336) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRiPd-00032N-Kx for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2016 10:35:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRiPX-0003lv-6I for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2016 10:35:09 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54199) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRiPX-0003lq-2I for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2016 10:35:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aRiPW-0006j5-Tx for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2016 10:35:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Fabrice Popineau Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Feb 2016 15:35: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.145468648525821 (code B ref 22534); Fri, 05 Feb 2016 15:35:02 +0000 Original-Received: (at 22534) by debbugs.gnu.org; 5 Feb 2016 15:34:45 +0000 Original-Received: from localhost ([127.0.0.1]:34554 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRiPE-0006iO-MS for submit@debbugs.gnu.org; Fri, 05 Feb 2016 10:34:45 -0500 Original-Received: from mail-ob0-f175.google.com ([209.85.214.175]:33060) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRiPC-0006iA-UV for 22534@debbugs.gnu.org; Fri, 05 Feb 2016 10:34:43 -0500 Original-Received: by mail-ob0-f175.google.com with SMTP id is5so90634479obc.0 for <22534@debbugs.gnu.org>; Fri, 05 Feb 2016 07:34:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KmFw+dOftVEfTCDGCRtg4QmaxXiKoK+R3evtkHk1Vqk=; b=rq3graGLqmrkaQ/fyqeTNJ7lDpagEacLP314gl221W9MorLo9CpRM0ROQn1uiGtlXs Xc2x16gLSOpH8rfgO3yNwdjKyfIF/1HUlsoc93N5WI0sW585lRJ0aWL6Wyqb+r07rFjn ULsVYzw9ifAQqKy3PdbX+y+kjVf+l3/CNVRvVw9hV6TrpQ44PG0w2ZW3wYqTyAIIQVkF O05MSbB8VVWFXR1wk7wc1AMxzGEdvWPo39UQCtioJp5UxYck9o8TqMVRXamOsGGnp7Ji RZlm/MrmvQvQGgkh5XM7ID8wVep08aVGFpx6eYTjpJ9y5Z4WaHOKCNM+2/NPIsP9silg 6WsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=KmFw+dOftVEfTCDGCRtg4QmaxXiKoK+R3evtkHk1Vqk=; b=c5L895YwTWUWg6vuDIcC0NTvoSHWYev5kyEhVvue1syqwc64h4Zraa/plJtY2YXrU+ K+fSXsRVnOU3/Y6rBwjE5M7Dow1qjP0mZnikTaOjIzDCuhUl7VCSVP0xVuxP11UTA7Ox 3K9v0QP2tNuYxy1mySxNGMNojYNeU1Mns4B3AGSb5uBzNNsEXAdorV+6zYSYZZu2Q+SX rOVDbfA47+8z04jkrfI3yucVWNi/HuhDFDDAeg6D+s6UbraIrH2qjCzBrLB3XlDzzt+4 BVWPWRRZg0YJJfyQmN71TJxCm9dIJY6MLiAMZ3LCMSvpyJN8IIG/lszl/Bk/IW2qRBns y96Q== X-Gm-Message-State: AG10YORA4LNUAeARA7LQccKQVQQrFUuMCNDw7ATePDp1ZroPj7YRwUWbDL1LT+wmp8A5QVimQQ88FW6VZ8gx6w== X-Received: by 10.182.73.225 with SMTP id o1mr13224285obv.80.1454686477390; Fri, 05 Feb 2016 07:34:37 -0800 (PST) Original-Received: by 10.202.78.67 with HTTP; Fri, 5 Feb 2016 07:34:17 -0800 (PST) In-Reply-To: <83fux7v56c.fsf@gnu.org> 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:112495 Archived-At: --089e0160b7c6be9a43052b079638 Content-Type: text/plain; charset=UTF-8 2016-02-05 11:10 GMT+01:00 Eli Zaretskii : > > From: Fabrice Popineau > > Date: Fri, 5 Feb 2016 06:59:00 +0100 > > Cc: Michael Albinus , 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 --089e0160b7c6be9a43052b079638 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


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
>

>=C2=A0 > Once the limit is reached, only the first notification is r= eturned.
>
>=C2=A0 What do you mean by "the first notification"? AFAIU, t= he 1000 events
>=C2=A0 are generated as 500 pairs of renames, so what is "the firs= t" here,
>=C2=A0 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 som= e
threshold, like 260, the test reports only the first pair of renames,
is that true?

=C2=A0
Yes, this is what I observe with dif= ferent values of n.

=C2=A0
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.
=C2=A0
Or maybe the preceding series of file creations is the= culprit, and we
should give Emacs more time to report them?
=C2=A0
I have tried with different values of=C2=A0file-notify--test-timeout= but it doesn't seem
to make any difference. I also boosted t= he size of the file_notifications[] array (* 16)
without any diff= erence. 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.=C2=A0 If my reading of the test is<= br> correct, it first creates 2000 files, and then issues 1000 renames,
which on Windows generate 2000 notifications.=C2=A0 Together, these add up<= br> to 4000, which is awfully close to the 4096 size of the Emacs input
event queue.=C2=A0 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?=C2=A0 Or maybe we are hitting on some limit of
Windows messages that can be enqueued?


I would have expected some Win32 funct= ion to error at some point ?

Also, would it be use= ful to use the overlap mechanism ? Would it help to overcome this kind of l= imitation ?
=C2=A0
(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?=C2=A0 Perhaps Michael can
explain.)

>=C2=A0 I've just found a serious problem, see bug#22557. I'm no= t sure it is
>=C2=A0 related to what you see here, but IMO until that bug is resolved= ,
>=C2=A0 there's no sense in trying to analyze what happens with noti= fications
>=C2=A0 on MS-Windows.
>
> Ok, I have seen that. Maybe I'll try to comment out the part of th= e 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-test= 06-many-events but I would have expected it.
=C2=A0
Btw, are you doing this on master or on emacs-25?=C2=A0 The files involved<= br> seem to be identical for now, but they might diverge in the future.

emacs-25 at this time.

Fabrice

--089e0160b7c6be9a43052b079638--