GNU bug report logs - #45117
28.0.50; process-send-string mysteriously exiting non-locally when called from timer

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: João Távora <joaotavora <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 45117 <at> debbugs.gnu.org
Subject: bug#45117: 28.0.50; process-send-string mysteriously exiting non-locally when called from timer
Date: Thu, 10 Dec 2020 13:37:59 -0500

> I'm not sure.  Every such async system eventually boils down
> to a point that sends something to the wire (step A) and a process
> filter (step C) that runs later on and finds some suitable "continuation",
> (a callback).

[ I'm not completely sure I understand your scenario above, so we may
  be miscommunicating.  ]

Right.  And `while-no-input` should only wrap the execution of A, so if
A doesn't complete, then presumably none of C nor B will want to be
executed, which seems OK.

IOW the only real problem is if A is interrupted before completing but
after starting to send something on the wire.  In that case, the
subprocess may left hanging waiting for more data.  This can be handled
in two different ways: by inhibiting quit around the "sends" (I
generally recommend against inhibiting quit, so it's not the option
I favor) or by using an unwind-protect that "kills" the subprocess or
closes the pipe in case we're exiting before having sent all the data
(that's a good idea to do also in case a bug signals an error).

> Actually, thinking more about it. I don't think it's sound to have a
> while-no-input at all under library control.  A programmer using
> that library should be given a predictable evaluation model.  At
> any rate, this is a regression from 26.3, where things didn't work
> like this.

The exact same problem affects all normal Elisp code when the user hits
C-g, so I think the better path forward is to make sure it's "easy and
natural" to write code which reacts correctly when it's aborted at some
arbitrary time.  We usually get that via `unwind-protect`, but if it's
not enough we should develop better solutions rather than shy away from
`quit`.

But I had the impression that the original problem under discussion was
not just due to the difficulty of writing code that handles "random
aborts", but rather due to the fact that `while-no-input` sometimes caused
undesired random aborts even when the user didn't hit any key.
This would be a bug in `while-no-input` which we should investigate
a fix (it's likely due to some "innocuous" event being received which
`while-no-input` mistakes for user-input; could be an event linked to
some kind of notification service like dbus, file-notifications, ...).


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.