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

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

[Stefan Monnier]

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


        Stefan

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

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

But all calls to `accept-process-output' in Gnus is called with a
timeout parameter, so there's no way Emacs could totally lock up.  I
think.  (It's typically called with a 0.1s or 0.01s timeout.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

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

[joakim]

Stefan Monnier <monnier@iro.umontreal.ca> 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.

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

>
>
>         Stefan

-- 
Joakim Verona

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

[Stefan Monnier]

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

[joakim]

Stefan Monnier <monnier@iro.umontreal.ca> 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

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

[Lars Magne Ingebrigtsen]

joakim@verona.se writes:

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

Does Emacs freeze immediately, or does it freeze the next time you try
to access the NNTP server?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

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

[Stefan Monnier]

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

Because these are run asynchronously, so in most cases the user has no
idea that code is being executed at that point.  So if she hits C-g it's
likely to be for other reasons than to interrupt the async code, so by
default Emacs runs the async code to completion first and then processes
the C-g (you wouldn't want a C-g meant to abort a command to result in
a half-font-locked display, would you?).  I.e. if you want to execute
code that may last for a significant amount of time from one of those
places, you need with-local-quit (and you may want to make sure the user
knows that such code is being run).


        Stefan

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

[Tom Tromey]

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

[ emacs hanging ]
Stefan> (IIRC, one such is during hostname lookup, but I don't know of
Stefan> any such case once the TCP connection is established).

I've been bitten by this a number of times.

It seems to me that Emacs could either resolve names in a separate
thread (so the originating thread could handle other I/O and be
interruptable) or do the work in a subprocess.

Tom

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

[Stefan Monnier]

> [ emacs hanging ]
Stefan> (IIRC, one such is during hostname lookup, but I don't know of
Stefan> any such case once the TCP connection is established).
> I've been bitten by this a number of times.
> It seems to me that Emacs could either resolve names in a separate
> thread (so the originating thread could handle other I/O and be
> interruptable) or do the work in a subprocess.

I'd tend to agree.  Patches welcome.  Maybe the concurrency extension
will resolve this problem eventually.


        Stefan

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

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

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

Is there a way to get a backtrace instead of the warning?  By looking at
the code, I can't tell where the message comes from.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen