in reply to Re: Setting signal handlers considered unsafe?
in thread Setting signal handlers considered unsafe?

Hi,

First of all, thanks everybody for your numerous replies :)

Second, I guess I should have written in my original post. I know a tight loop of setting a local signal handler is silly, just like calling kill in another tight loop. I don't do that in my code, really. It's just the simplest way of reproducing the issue. It happens, say, once a week in the real world and once a second in the demo code.

Third, I do have a pretty good grasp of multiprocessing issues, including atomicity of signal handlers and (simplifying a bit) non-sharing of address space between different processes. I don't expect to learn why local $SIG{FOO} = \&bar; is silly, I expect to learn why it isn't atomic and what I can do about it.

I have tried sigprocmask together with the totally undocumented POSIX::SigSet (does it have something like ->add?) but I can still easily "crash" perl with this code. Avoiding local and setting/resetting the handler "by hand" seemed to decrease the frequency in the real world but the race still exists.

Also, strace shows that perl internally does mostly the same thing (block signal, call sigaction, unblock) when setting the handler so I don't think there's anything more I can do, other than cry for help in the Monastery ;)

  • Comment on Re^2: Setting signal handlers considered unsafe?

Replies are listed 'Best First'.
Re^3: Setting signal handlers considered unsafe?
by djp (Hermit) on Nov 06, 2008 at 01:12 UTC
    ... totally undocumented POSIX::SigSet ... Try POSIX
      D'oh! I've read through that page numerous times (and have learnt of POSIX::SigSet from there) without ever seeing it. My apologies.