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

[joakim]

Stefan Monnier <address@hidden> writes:

>>>> 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).

But why then is quit inhibited at all?

Anyway, the freeze is quite easily reproducible. (as have been described in some
old bug reports)

- start gnus, make sure you read some nntp groups so nntp sockets are
  open
- make your network interface go away somehow (disconnecting 3g or
  something, but simply ifconfiging away should also work)
- stare in horror as your emacs freezes

This particular problem happens to me so often I have written a
workaround script like this:

,----
| #/bin/sh
| `lsof -n|grep emacs|grep nntp|sed "s/.*TCP\ \\([^:]*\\):.*->\\([^:].*\\):.*/  
export a=\\1 export b=\\2/"`
| echo $a $b
| ifconfig eth2:1 $a
| ifconfig eth2:2 $b
| echo press enter when emacs is alive
| read
| ifconfig eth2:1 down
| ifconfig eth2:2 down
`----

since the socket is left even though the interface is gone, the script
ifconfigs new interfaces with information gleaned from the hanging
socket. After a while Emacs will live again, and the interfaces can be
removed.

>> 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

-- 
Joakim Verona