> -----Original Message-----
> 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 */
>     }
> #endif
> 
> And 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 ;-)