From: Masschelein Bart Date: 2005-07-06T00:54:06+09:00 Subject: Re: Abort a system call > -----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 ;-)