[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Blocking call to accept-process-output with quit inhibited!! [11 tim
From: |
Stefan Monnier |
Subject: |
Re: Blocking call to accept-process-output with quit inhibited!! [11 times] |
Date: |
Tue, 07 Sep 2010 12:38:33 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
>>> 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
Re: Blocking call to accept-process-output with quit inhibited!! [11 times], Lars Magne Ingebrigtsen, 2010/09/07