Re: Blocking call to accept-process-output with quit inhibited!! [11 times]

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>> In Emacs 24, I get this message the first time I enter a Gnus group.
>>> What does it mean, and what can I do to make it go away?
>> It means just that: accept-process-output is called in a way that can
>> block (e.g. because some remote host doesn't respond) wit inhibit0quit
>> set to a non-nil value, which means that Emacs may end up frozen (with
>> no way to wake it up) for as long as the remote machine decides not
>> to answer.
>> IOW, maybe there should be a (with-local-quit ...) somewhere so that the
>> user can C-g out of such a state (or the call should have a timeout, or
>> inhibit-quit should not be set, ...).

> I get bitten by this quite a lot, since I'm often on a flaky 3g
> line. When the link goes down, and some Emacs socket is still up, Emacs
> freezes. This is quite annoying.

Emacs should not freeze in such a case.  IIUC most cases where this
happen are Elisp bugs (typically a missing with-local-quit or something
like that), tho there are a few cases where it's a problem at the
C level (IIRC, one such is during hostname lookup, but I don't know of
any such case once the TCP connection is established).

> I suppose that the hard blocking is there to prevent data loss or
> whatever, but having to kill -9 Emacs results in worse dataloss.

No, usually it's there because the Elisp coder is not aware of the risk
(e.g. he doesn't realize his code will be run with inhibit-quit set,
probably because he doesn't realize that this is set whenever we run
process filters, process sentinels, post-command-hook, jit-lock,
timers, and a handful other cases).


        Stefan