It appears that functions that are waiting are not interrupted by a 
signal being handled. The wait just continues, although I would expect 
it to raise Errno::EINTR.

Is this intentional or a bug? (I'm using version 1.6.6 under Linux -- 
apologies if this behavior is changed in a later version.)

The following code shows the behavior. In one shell, run this program 
which sets up a signal handler, prints its PID, and waits.

----------------------------
trap("USR1") {p "handler invoked"}
p Process.pid
begin
    p $stdin.read(1)
rescue => e
    p e
end
----------------------------

In another shell, send a SIGUSR1 signal to the above process:

  ruby -e 'Process.kill("USR1", <the printed pid>)'

The signal handler is invoked, but the wait is not interrupted. If Enter 
is typed in the first shell, the program prints the input and terminates 
(since its IO request is satisfied).

This seems like a bug to me, since a signal handler typically sets a 
state that needs to be examined by the program's main flow of control. 
If that doesn't happen, it can be impossible to respond to signals in a 
timely way .


Bob