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 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 .
p Process.pid
begin
p $stdin.read(1)
rescue => e
p e
end
$ ruby xx.rb
3195
xx.rb:4:in `read’: SIGUSR1 (SignalException)
from xx.rb:4
···
On Wednesday 10 July 2002 02:53 pm, Bob Alexander wrote:
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).
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.
Because it’s handled.
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 .
trap(“USR1”) {
p “handler invoked”
raise SignalException.new(“SIGUSR1”)
}
p Process.pid
begin
p $stdin.read(1)
rescue SignalException => e
p e
end
···
At Thu, 11 Jul 2002 06:53:08 +0900, Bob Alexander wrote: