From: "ara.t.howard" <ara.t.howard@...>
Date: 2008-06-03T03:24:49+09:00
Subject: Re: Traping signals on child processes


On Jun 2, 2008, at 11:36 AM, Mário Lopes wrote:

> What I'm precisely trying to do is trapping the SIGINT signal from
> getting to the child so it doesn't abort. I've been unable to do  
> this. I
> can get it on the main process though but can't prevent it from being
> relayed to the child process.

you need interject another process:

#
# Start main process
#  Start system/child process
#    INT signals can't stop whatever the system call is doing
#  End system/child process
#  If INT signal detected, exit, otherwise, continue running
# End main process
#

def system_critical command
   signaled = false
   int = trap('INT'){ puts "signaled #{ $$ }"; signaled = true }
   begin
     pid = fork{ system command }
     Process.kill 'INT', pid
     Process.waitpid pid
   ensure
     trap('INT', int)
   end
   exit 15 if signaled
end


# use thread just so we can run *and* send ourselves a signal

thread = Thread.new do
   system_critical "ruby -e' sleep 1 and puts :done' "
end

Process.kill 'INT', Process.pid

thread.join

cfp:~ > ruby a.rb
signaled 25656
signaled 25657
done


cfp:~ > ruby a.rb
signaled 25660
signaled 25661
done




this is because you have to no wait to install signal handlers in the  
code the system call runs - it can do whatever it wants.  what you can  
do is cause a child process which *does* ignore INT to run that system  
command.  the reason you need the second child is that ruby's system  
call is going to do it's own signal management of INT.



a @ http://codeforpeople.com/
--
we can deny everything, except that we have the possibility of being  
better. simply reflect on that.
h.h. the 14th dalai lama