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: João Távora <joaotavora <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
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 18:05:54 +0000

On Thu, Dec 10, 2020 at 5:51 PM Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
>
> > Aha! I found the culprit.  It is eldoc.el.  It seems to be a
> > longstanding policy to call Eldoc backends with `with-no-input`.  This
> > is obviously badly problematic for aynchronous backends.
>
> Maybe "obviously" so from a pragmatic point of view, but in
> a theoretical sense, I don't see why:

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).  To find that suitable continuation it has to be added
to the continuation registry (step B). I'd say step A and B have to
be atomic, whatever the order.  If you interrupt between
A and B you get either an unexpected reply. If you interrupt between
B and A you get a stale leftover continuation.  Both are inconsistent
state, in my opinion.

There are workarounds for all of this, but I think this while-no-input
isn't conceptually sound there, for this reason.

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.

João

Previous Next

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