A
andrew
I use an init system written in ruby for my Gnu/linux distro, and it
makes heavy use of signal handling.
After upgrading (stable snapshots)
from
ruby 1.8.3 (2005-10-26)
to
ruby 1.8.5 (2006-10-18)
nothing much works any more. It seems that signals are no longer
delivered until _after_ a blocking system call returns. For example:
#!/bin/ruby -w
trap("USR1") { puts("USR1") }
fork { sleep 60 }
pid = Process::wait()
If you run this up under a recent snapshot and fire some signals at
the process with
kill -USR1 <pid>
you will get no "USR1" output until AFTER the 60seconds have elapsed and
Process::wait() returns.
The old behaviour was to handle signals immediately, with presumably
SA_RESTART (or whatever it is called) set such that the wait system call
just carries on unaffected after the signal handler has been run.
So, is the change intentional? If so, whats the rationale?
Andrew Walrond
makes heavy use of signal handling.
After upgrading (stable snapshots)
from
ruby 1.8.3 (2005-10-26)
to
ruby 1.8.5 (2006-10-18)
nothing much works any more. It seems that signals are no longer
delivered until _after_ a blocking system call returns. For example:
#!/bin/ruby -w
trap("USR1") { puts("USR1") }
fork { sleep 60 }
pid = Process::wait()
If you run this up under a recent snapshot and fire some signals at
the process with
kill -USR1 <pid>
you will get no "USR1" output until AFTER the 60seconds have elapsed and
Process::wait() returns.
The old behaviour was to handle signals immediately, with presumably
SA_RESTART (or whatever it is called) set such that the wait system call
just carries on unaffected after the signal handler has been run.
So, is the change intentional? If so, whats the rationale?
Andrew Walrond
