From: Guillaume Marcais [mailto:guslist@free.fr]
Sent: Tuesday, July 05, 2005 16:55
To: ruby-talk ML
Subject: Re: Abort a system call> > With parts of other pieces today on the reflector, I
assembled this
> >
> > --------
> > pid = Process.fork do
> > exec($decoder, $bitstreamPath, $yuvOutputPath)
> > end
> >
> > trap "SIGINT", proc{ Process.kill("SIGINT", pid); print "^C
> > was pressed. Process id #{pid}\n" }
> >
> > Process.waitpid(pid)
> > --------
> For those having similar problems, I just solved it by
>
> trap "INT", proc{ Process.kill(9, pid) }
>
> so using a hard kill.
>
> If people have more elegant ways of solving this, let me know!Here is what I think is going on. Ruby sets up the signal handler so
that some system call will resume after the interrupt instead of
returning with EINTR:from ruby-signal in signal.c:
#if defined(SA_RESTART)
/* All other signals but VTALRM shall restart restartable syscall
VTALRM will cause EINTR to syscall if interrupted.
*/
if (signum != SIGVTALRM) {
sigact.sa_flags |= SA_RESTART; /* SVR4, 4.3+BSD */
}
#endifAnd from man sigaction:
SA_RESTART
Provide behaviour compatible with BSD signal
semantics by
making certain system calls restartable across
signals.That is why Process.waitpid(pid) doesn't return until your decoder
process dies. Maybe Perl doesn't do that and it would explain the
difference of behavior.
Wow. A lot of magic going on behind the scenes... I have to catch up big time ;-).
Second, it seems that your decoder process doesn't terminate on a
SIGINT. Maybe you should send a SIGTERM, to be a little more graceful
than SIGKILL (9).
Also about these signals I have to learn, but for now I can tell you that SIGTERM works also perfect to do what I want.
Hope it helps,
Guillaume.
It does! Thanks!
PS: people in the know, please correct me if I got it wrong about the
way the signals are handled.
I'll get back to you later
ยทยทยท
-----Original Message-----