From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#32986: 27.0.50; unexpected delay in while-no-input + accept-process-output Date: Mon, 8 Oct 2018 21:06:12 +0100 Message-ID: References: <83sh1gzdey.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000e5bcdf0577bd2766" X-Trace: blaine.gmane.org 1539029116 4283 195.159.176.226 (8 Oct 2018 20:05:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 8 Oct 2018 20:05:16 +0000 (UTC) Cc: 32986@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 08 22:05:12 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g9bmB-0000zJ-AH for geb-bug-gnu-emacs@m.gmane.org; Mon, 08 Oct 2018 22:05:11 +0200 Original-Received: from localhost ([::1]:48105 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g9boH-00085B-SL for geb-bug-gnu-emacs@m.gmane.org; Mon, 08 Oct 2018 16:07:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36980) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g9bo5-000854-KG for bug-gnu-emacs@gnu.org; Mon, 08 Oct 2018 16:07:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1g9bo0-0007Ef-KC for bug-gnu-emacs@gnu.org; Mon, 08 Oct 2018 16:07:09 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36545) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1g9bny-0007Cm-SX for bug-gnu-emacs@gnu.org; Mon, 08 Oct 2018 16:07:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1g9bny-0004zK-GX for bug-gnu-emacs@gnu.org; Mon, 08 Oct 2018 16:07:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Oct 2018 20:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 32986 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 32986-submit@debbugs.gnu.org id=B32986.153902919319132 (code B ref 32986); Mon, 08 Oct 2018 20:07:02 +0000 Original-Received: (at 32986) by debbugs.gnu.org; 8 Oct 2018 20:06:33 +0000 Original-Received: from localhost ([127.0.0.1]:40803 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g9bnU-0004yV-SM for submit@debbugs.gnu.org; Mon, 08 Oct 2018 16:06:33 -0400 Original-Received: from mail-qk1-f169.google.com ([209.85.222.169]:39176) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g9bnT-0004yG-0N for 32986@debbugs.gnu.org; Mon, 08 Oct 2018 16:06:31 -0400 Original-Received: by mail-qk1-f169.google.com with SMTP id q5-v6so12854681qki.6 for <32986@debbugs.gnu.org>; Mon, 08 Oct 2018 13:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=POkDKs5rbMZreIolRIIEb6tiyVKf9EzWbAEtXBxwedU=; b=kmwkN5vY26CU/OJ/NbUfRwVMFfO/kKt8QzuybR/kBc7RyVBDJu+pHT7Q284DtGlPfd kpz4jVy4+Y6uNgsIfBvr8Cmt08hpk5wWvWi3Ay2RE1ob8YETqQ5Q0rLjFC4uBBS2XU4B FsML1iz4OhWcD4rI7JbnhLTwSk6rgQOmMgvMkitSySUPVzCDS781h+fMoZ4MtB5vTFkO bC7QmOIFG2Uns14FDTZo3DU3KdC9+uw6SZiE7o1GNz+aKxeAKfn5IF+7Et1iwUDDtQQf Ord3kMpT41GFwt0XIrHxiH8fwWiU5bblmwdnKmQpfhHKVajdeRDqspC3j+qoBc07VILa xEag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=POkDKs5rbMZreIolRIIEb6tiyVKf9EzWbAEtXBxwedU=; b=U7Cr7ge7sVvUXRpThKJd+WqBEZW4xqQssAzSyX/rUw6fMPvgOq+PWmO2tRA9UNT73Z YIcBnPzpfbQOUCnk3w+STreNg1LGYA55I9VpadPJIofJWP3XLu72/o5IqrARw1pc0ybG VU6hJAavt7g5ypHx2dMtSmdwltHS5tMFNJ4zCNV0Z/r92vXm87loJ85RStLSLt7cR9ni C1ZVrCBRP0f40Nvg9AJfArioo7mwU/JhCR56xdVGVvbGFuc3GH/0Acv9AAntIclmZDMj EAo4s+tgCa+dYxzT5uRN79GN3fpMv7jddXXscGe7kb6s/EG3BoKlqN6Lh/yzn5VIfjP1 IBSg== X-Gm-Message-State: ABuFfoiyJElC3y3Kh+KCeHWSif2OtUmowgeHmyVHK5BoqbzBvf0PZoUU JUjj8rc8wpA5EjYoasHegFuXXWpIQhCwd3HKiqo= X-Google-Smtp-Source: ACcGV604qrUd+tjZXoEV73ob8yOQAostg6AqVxVnbnTwy+b/4Q9jsx2HdPqFKXmlI1BMoNOLVhPcORI146pjbLSGGKY= X-Received: by 2002:a37:6882:: with SMTP id d124-v6mr19246878qkc.96.1539029185443; Mon, 08 Oct 2018 13:06:25 -0700 (PDT) In-Reply-To: <83sh1gzdey.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" Xref: news.gmane.org gmane.emacs.bugs:151020 Archived-At: --000000000000e5bcdf0577bd2766 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Eli, I will fully read and process your thorough reply later tonight or tomorrow, but in the meantime let me just restate, or clarify in case it wasn't clear, that I expect the 30s, 15s and 0.1s case to break equally as quickly, namely as quick as I can type the first input. And indeed that's what happens on Linux and Mac OSX, but not on Windows. If your reply already addresses this apparent discrepancy, then I apologize for my premature clarification in advance. Thanks, Jo=C3=A3o On Mon, Oct 8, 2018, 16:06 Eli Zaretskii wrote: > > From: Jo=C3=A3o T=C3=A1vora > > Date: Mon, 08 Oct 2018 11:48:01 +0100 > > > > I would expect while-no-input to break out of accept-process-output ver= y > > quickly after user keyboard input. These expectations are met except > > for some situations. > > I think your expectations are incorrect. My expectations are that if > you call accept-process-output with a timeout of 30 sec, then > while-no-input will return after 30 sec plus a small delay. It's just > that in order to see this in action, your experiment must be done in a > "clean room", and that is not easy. > > First, one basic fact: accept-process-output calls > wait_reading_process_output in a way that instructs it not to wait for > keyboard input, you can see that clearly in the code (read_kbd is > passed as zero). This means that wait_reading_process_output will > call pselect with the timeout of 30 sec (in your case), and will wait > that long before it returns (unless there's a subprocess that gives us > some stuff). So why would you expect while-no-input that calls > accept-process-output with that timeout to return earlier? > > Maybe you expect while-no-input to interrupt the pselect call when you > press SPC? But that's not how keyboard input works in Emacs. In some > configurations (e.g., GUI frame on X), keyboard input indeed delivers > a signal to Emacs, but the signal handler just sets a flag and > returns, it doesn't jump out of the pselect call. It is then the job > of the running Lisp code to check whether keyboard input is available, > and act accordingly: set the quit-flag, and then test that flag soon > enough to return from while-no-input. But since the "running Lisp > code" is in this case stuck in the pselect call, it cannot do anything > before pselect returns, right? > > Now to the "clean room" part: the reason why you don't always see this > 30-sec delay is because there are several factors that "contaminate" > the picture: > > . timers -- these cause us to reduce the timeout until the > expiration time of the next timer, so pselect returns earlier than > after 30 sec > . the first time wait_reading_process_output is called, it almost > immediately checks for available keyboard input, before it calls > pselect > > Therefore, to see the 30-sec delay, you need: > > . stop all timers, which in "emacs -Q" means: > . disable blink-cursor-mode > . disable global-eldoc-mode > . disable font-lock-mode > . cancel the undo--auto-bindary-timer (I did that via list-timers) > . type "C-u C-x C-e", wait for a few seconds, and only then type SPC > > If I do all of the above, I see 30 sec plus a small delay every time I > run your 2nd test. > > > I tried quickly pluggin GDB in at the right time, but I don't know if > > I'm using the right GDB (using msys's which is pretty slow) and I > > probably should be using an unoptimized Emacs. Anyway, as a start this > > is what "bt full" look like: > > > > (gdb) bt full > > #0 0x00007ffc97b0d8c1 in ntdll!DbgBreakPoint () from > /c/WINDOWS/SYSTEM32/ntdll.dll > > No symbol table info available. > > #1 0x00007ffc97b39a0b in ntdll!DbgUiRemoteBreakin () from > /c/WINDOWS/SYSTEM32/ntdll.dll > > No symbol table info available. > > #2 0x00007ffc952b3034 in KERNEL32!BaseThreadInitThunk () > > from /c/WINDOWS/System32/KERNEL32.DLL > > No symbol table info available. > > #3 0x00007ffc97ae1461 in ntdll!RtlUserThreadStart () from > /c/WINDOWS/SYSTEM32/ntdll.dll > > No symbol table info available. > > #4 0x0000000000000000 in ?? () > > On Windows, when you attach a debugger to a program, the OS creates a > special thread in the debuggee, and that is the thread whose backtrace > you see here. That thread is never an interesting one, so the first > thing you need to do after attaching is switch to the Lisp thread, by > typing "thread 1" at the GDB prompt. Then the backtrace will make > much more sense. > > > Backtrace stopped: previous frame inner to this frame (corrupt stack= ?) > > (gdb) xbacktrace > > Undefined command: "xbacktrace". Try "help". > > > > xbacktrace probably failed because of some Python error loading .gdbini= t > > No, it says "Undefined command", which means it doesn't know what > xbacktrace is. You probably didn't start GDB from the Emacs's src > directory, so it didn't read the .gdbinit file which defines that > command. You can do that manually by typing the command > > (gdb) source /path/to/emacs/src/.gdbinit > > (This last part is not specific to Widnows.) > --000000000000e5bcdf0577bd2766 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Eli,

I= will fully read and process your thorough reply later tonight or tomorrow,= but in the meantime let me just restate, or clarify in case it wasn't = clear, that I expect the 30s, 15s and 0.1s case to break equally as quickly= , namely as quick as I can type the first input.
And indeed that's what happens on Linux and Ma= c OSX, but not on Windows.=C2=A0 If your reply already addresses this appar= ent discrepancy, then I apologize for my premature clarification in advance= .

Thanks,
Jo=C3=A3o


=

On Mon, Oct 8, = 2018, 16:06 Eli Zaretskii <eliz@gnu.org<= /a>> wrote:
> From: Jo=C3=A3o= T=C3=A1vora <joaotavora@gmail.com>
> Date: Mon, 08 Oct 2018 11:48:01 +0100
>
> I would expect while-no-input to break out of accept-process-output ve= ry
> quickly after user keyboard input.=C2=A0 These expectations are met ex= cept
> for some situations.

I think your expectations are incorrect.=C2=A0 My expectations are that if<= br> you call accept-process-output with a timeout of 30 sec, then
while-no-input will return after 30 sec plus a small delay.=C2=A0 It's = just
that in order to see this in action, your experiment must be done in a
"clean room", and that is not easy.

First, one basic fact: accept-process-output calls
wait_reading_process_output in a way that instructs it not to wait for
keyboard input, you can see that clearly in the code (read_kbd is
passed as zero).=C2=A0 This means that wait_reading_process_output will
call pselect with the timeout of 30 sec (in your case), and will wait
that long before it returns (unless there's a subprocess that gives us<= br> some stuff).=C2=A0 So why would you expect while-no-input that calls
accept-process-output with that timeout to return earlier?

Maybe you expect while-no-input to interrupt the pselect call when you
press SPC?=C2=A0 But that's not how keyboard input works in Emacs.=C2= =A0 In some
configurations (e.g., GUI frame on X), keyboard input indeed delivers
a signal to Emacs, but the signal handler just sets a flag and
returns, it doesn't jump out of the pselect call.=C2=A0 It is then the = job
of the running Lisp code to check whether keyboard input is available,
and act accordingly: set the quit-flag, and then test that flag soon
enough to return from while-no-input.=C2=A0 But since the "running Lis= p
code" is in this case stuck in the pselect call, it cannot do anything=
before pselect returns, right?

Now to the "clean room" part: the reason why you don't always= see this
30-sec delay is because there are several factors that "contaminate&qu= ot;
the picture:

=C2=A0 . timers -- these cause us to reduce the timeout until the
=C2=A0 =C2=A0 expiration time of the next timer, so pselect returns earlier= than
=C2=A0 =C2=A0 after 30 sec
=C2=A0 . the first time wait_reading_process_output is called, it almost =C2=A0 =C2=A0 immediately checks for available keyboard input, before it ca= lls
=C2=A0 =C2=A0 pselect

Therefore, to see the 30-sec delay, you need:

=C2=A0 . stop all timers, which in "emacs -Q" means:
=C2=A0 =C2=A0 . disable blink-cursor-mode
=C2=A0 =C2=A0 . disable global-eldoc-mode
=C2=A0 =C2=A0 . disable font-lock-mode
=C2=A0 =C2=A0 . cancel the undo--auto-bindary-timer (I did that via list-ti= mers)
=C2=A0 . type "C-u C-x C-e", wait for a few seconds, and only the= n type SPC

If I do all of the above, I see 30 sec plus a small delay every time I
run your 2nd test.

> I tried quickly pluggin GDB in at the right time, but I don't know= if
> I'm using the right GDB (using msys's which is pretty slow) an= d I
> probably should be using an unoptimized Emacs.=C2=A0 Anyway, as a star= t this
> is what "bt full" look like:
>
>=C2=A0 =C2=A0 (gdb) bt full
>=C2=A0 =C2=A0 #0=C2=A0 0x00007ffc97b0d8c1 in ntdll!DbgBreakPoint () fro= m /c/WINDOWS/SYSTEM32/ntdll.dll
>=C2=A0 =C2=A0 No symbol table info available.
>=C2=A0 =C2=A0 #1=C2=A0 0x00007ffc97b39a0b in ntdll!DbgUiRemoteBreakin (= ) from /c/WINDOWS/SYSTEM32/ntdll.dll
>=C2=A0 =C2=A0 No symbol table info available.
>=C2=A0 =C2=A0 #2=C2=A0 0x00007ffc952b3034 in KERNEL32!BaseThreadInitThu= nk ()
>=C2=A0 =C2=A0 =C2=A0 =C2=A0from /c/WINDOWS/System32/KERNEL32.DLL
>=C2=A0 =C2=A0 No symbol table info available.
>=C2=A0 =C2=A0 #3=C2=A0 0x00007ffc97ae1461 in ntdll!RtlUserThreadStart (= ) from /c/WINDOWS/SYSTEM32/ntdll.dll
>=C2=A0 =C2=A0 No symbol table info available.
>=C2=A0 =C2=A0 #4=C2=A0 0x0000000000000000 in ?? ()

On Windows, when you attach a debugger to a program, the OS creates a
special thread in the debuggee, and that is the thread whose backtrace
you see here.=C2=A0 That thread is never an interesting one, so the first thing you need to do after attaching is switch to the Lisp thread, by
typing "thread 1" at the GDB prompt.=C2=A0 Then the backtrace wil= l make
much more sense.

>=C2=A0 =C2=A0 Backtrace stopped: previous frame inner to this frame (co= rrupt stack?)
>=C2=A0 =C2=A0 (gdb) xbacktrace
>=C2=A0 =C2=A0 Undefined command: "xbacktrace".=C2=A0 Try &quo= t;help".
>
> xbacktrace probably failed because of some Python error loading .gdbin= it

No, it says "Undefined command", which means it doesn't know = what
xbacktrace is.=C2=A0 You probably didn't start GDB from the Emacs's= src
directory, so it didn't read the .gdbinit file which defines that
command.=C2=A0 You can do that manually by typing the command

=C2=A0 (gdb) source /path/to/emacs/src/.gdbinit

(This last part is not specific to Widnows.)
--000000000000e5bcdf0577bd2766--