Interruptible wait_for_termination

Interruptible wait_for_termination

[Eli Zaretskii]

The function wait_for_termination_1 can be "interruptible" if called
with its second argument non-zero.  But what it does is this:

  while (1)
    {
      int status;
      int wait_result = waitpid (pid, &status, 0);
      if (wait_result < 0)
	{
	  if (errno != EINTR)
	    break;
	}
      else
	{
	  record_child_status_change (wait_result, status);
	  break;
	}

      if (interruptible)
	QUIT;
    }

What I don't understand here is how can this be "interruptible" when
the process specified by PID did not yet exit, and the call to waitpid
blocks.  It seems that the only way to interrupt that blocking call is
to deliver a signal to Emacs, either SIGINT or some other signal that
would interrupt waitpid.  IOW, just C-g will _not_ break the above
loop (except on a TTY, where C-g generates a SIGINT).

So can someone please explain how exactly does a user interrupt this
"interruptible" waiting, if, say, the called process never exits?

I'm asking because I'd like to make the w32 emulation of waitpid
behave in the same way.  It currently checks for QUIT internally,
while it waits for the process to exit, but I'm not sure this is
identical to the Posix behavior.

TIA

Re: Interruptible wait_for_termination

[Paul Eggert]

On 11/10/2012 10:43 AM, Eli Zaretskii wrote:
> It seems that the only way to interrupt that blocking call is
> to deliver a signal to Emacs, either SIGINT or some other signal that
> would interrupt waitpid.

Doesn't SIGIO do the trick?  At least, on hosts
with USABLE_SIGIO, but I suspect that every non-tty platform
has a usable SIGIO these days, and that might
explain the symptoms you're observing.

Re: Interruptible wait_for_termination

[Eli Zaretskii]

> Date: Sat, 10 Nov 2012 13:31:48 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> On 11/10/2012 10:43 AM, Eli Zaretskii wrote:
> > It seems that the only way to interrupt that blocking call is
> > to deliver a signal to Emacs, either SIGINT or some other signal that
> > would interrupt waitpid.
> 
> Doesn't SIGIO do the trick?

Maybe it does, but when I considered this possibility, it sounded
incredible to me that every keystroke would normally interrupt a call
to waitpid.  Aren't there gobs of programs out there who call waitpid
without setting up a loop that checks for EINTR?

But if you say this is the case, then OK.  Thanks for the explanation.

Re: Interruptible wait_for_termination

[Paul Eggert]

On 11/10/2012 07:48 PM, Eli Zaretskii wrote:
> Aren't there gobs of programs out there who call waitpid
> without setting up a loop that checks for EINTR?

There are, but they typically have a race condition bug
unless they do something tricky with signals, which
Emacs no longer does and which I don't recommend.

Re: Interruptible wait_for_termination

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Maybe it does, but when I considered this possibility, it sounded
> incredible to me that every keystroke would normally interrupt a call
> to waitpid.  Aren't there gobs of programs out there who call waitpid
> without setting up a loop that checks for EINTR?

Those gobs of programs don't enable SIGIO.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Interruptible wait_for_termination

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Paul Eggert <eggert@cs.ucla.edu>,  emacs-devel@gnu.org
> Date: Sun, 11 Nov 2012 13:28:33 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Maybe it does, but when I considered this possibility, it sounded
> > incredible to me that every keystroke would normally interrupt a call
> > to waitpid.  Aren't there gobs of programs out there who call waitpid
> > without setting up a loop that checks for EINTR?
> 
> Those gobs of programs don't enable SIGIO.

Thanks, that must be the answer.  I failed to notice that SIGIO is
ignored by default.

But the platforms that don't have USABLE_SIGIO really cannot interrupt
that waitpid call, except on a TTY, right?

Re: Interruptible wait_for_termination

[Paul Eggert]

On 11/11/2012 08:30 AM, Eli Zaretskii wrote:
> platforms that don't have USABLE_SIGIO really cannot interrupt
> that waitpid call, except on a TTY, right?

That's the general idea, I'm afraid.  My impression is that
nobody has cared enough to get this to work well on
non-USABLE_SIGIO hosts such as Solaris and OpenBSD.
On these hosts, that 'waitpid' will hang until the
process finishes or some other random signal arrives.
So, for example, if you type M-x sleep 10 RET C-g,
then nothing happens for 10 seconds, until the
sleep returns.

Re: Interruptible wait_for_termination

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> What I don't understand here is how can this be "interruptible" when
> the process specified by PID did not yet exit, and the call to waitpid
> blocks. 

Coincidentally, I've been looking at the same code lately, and not
getting the point, either.

I run mplayer under Emacs to watch tv (as one does).  Sometimes mplayer
jams, and I hit `C-g' to kill it.  Emacs helpfully says "hit C-g again
to kill it immediately", and then the second `C-g' does absolutely
nothing useful.

Wouldn't it make more sense to have the second `C-g' do a "kill -9"
instead of what it's doing now?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Interruptible wait_for_termination

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Mon, 12 Nov 2012 06:13:06 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > What I don't understand here is how can this be "interruptible" when
> > the process specified by PID did not yet exit, and the call to waitpid
> > blocks. 
> 
> Coincidentally, I've been looking at the same code lately, and not
> getting the point, either.
> 
> I run mplayer under Emacs to watch tv (as one does).  Sometimes mplayer
> jams, and I hit `C-g' to kill it.  Emacs helpfully says "hit C-g again
> to kill it immediately", and then the second `C-g' does absolutely
> nothing useful.
> 
> Wouldn't it make more sense to have the second `C-g' do a "kill -9"
> instead of what it's doing now?

Not to me, it doesn't.  How can Emacs possibly know that this is what
you want?  What if you have some other process running under Emacs?
Etc., etc.

However, are you saying that typing C-g once does not make Emacs
responsive, so that you could kill the player manually?  IIUC from
this thread, if you are on GNU/Linux (or any other system that
supports USABLE_SIGIO), that C-g should have thrown you to top level,
assuming that the command in question doesn't inhibit quit.

Re: Interruptible wait_for_termination

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Not to me, it doesn't.  How can Emacs possibly know that this is what
> you want?  What if you have some other process running under Emacs?
> Etc., etc.

Well, `C-g' does kill off most processes that you start with
`call-process':

(call-process "sleep" nil nil nil "10")

Tap `C-g' and it'll say

Waiting for process to die...done
Quit

so it obviously knew what process to kill?  However, certain processes
like "mplayer" will give the dreaded "hit C-g again to kill immediately"
message, and `C-g' will do nothing useful that I can detect in that
situation.  I have to ssh into the TV machine and say "pkill mplayer" to
use Emacs again.

It would have been nicer if the second `C-g' killed immediately.  :-)

> However, are you saying that typing C-g once does not make Emacs
> responsive, so that you could kill the player manually?

Yes.

> IIUC from this thread, if you are on GNU/Linux (or any other system
> that supports USABLE_SIGIO), that C-g should have thrown you to top
> level, assuming that the command in question doesn't inhibit quit.

Perhaps mplayer inhibits that signal or something?  If Emacs is actually
sending that signal?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/