Robert Urban <[EMAIL PROTECTED]> writes: >Hi Nick, > >You wrote: >> Joshua N Pritikin <[EMAIL PROTECTED]> writes: >> >----- Forwarded message from Robert Urban <[EMAIL PROTECTED]> ----- >> > >> >To: [EMAIL PROTECTED] >> >Subject: Event and non-Event signal handlers on Linux >> >From: Robert Urban <[EMAIL PROTECTED]> >> >X-Seen: false >> >X-ID: [EMAIL PROTECTED] >> > >> >Hallo Joshua, >> > >> >hmm. I'm afraid I was a bit premature with my previous mail. >> > >> >It seems there are significant implementation differences between >> >Solaris and Linux. On Solaris, when I retrieve the exit status >> >of a process that caused a segmentation fault, I get what I expect, >> >namely a value with bit 8 set (128 decimal). It makes no difference >> >if I retrieve the status in an Event callback or using a simple >> >signal handler. >> > >> >On Linux, if I simply run my core-dumping program, I get an exit status >> >of 139 (decimal). If however I retrieve the status in an Event callback >> >or in a signal handler (makes no difference) I get 11 (decimal). strange. >> > >> >All this mucking about caused me to find another difference in Event's >> >behaviour on Solaris and Linux: >> > >> >In order to work around the problem I described in my previous mail, >> >I decided to catch SIGCHLD using my own signal hander, and then >> >use Event::timer() to create an event. The Event manpage implies >> >that this should work: >> > >> > signal => $str >> > The callback is invoked after the specified signal is received. >> > The $str string should be something like 'INT' or 'QUIT'. Also see >> > the documentation for %SIG. A given signal can be handled by %SIG >> > or Event, but not both. >> > >> > >> >However, on Linux, my signal handler is not getting called. On Solaris, >> >it again works as expected. >> > >> >As my target platform is Solaris, I'm not too distraught, but it's not >> >very encouraging to find the Linux implementation deviates so significantly >> >from the acceptable. When I write "implementation" I mean somewhere in: >> > kernel >> > libc >> > perl >> > Event >> > >> >I'm not accusing Event of being the culprit :). >> > >> >I'm using redhat with a 2.4.18 kernel. >> >> Are you using same perl versions on both platforms? > >what a very good question :) No. > >Linux: > This is perl, v5.8.0 built for i386-linux-thread-multi > >Solaris: > This is perl, v5.6.1 built for sun4-solaris >
I suspected as much ;-) Perl5.8 has "synchronous signals" - to avoid the age-old problem of INT arriving while perl was in malloc() and anything perl did in the handler corruping the heap and eventually segfaulting in 5.8 we just record that the signal occured. Then when perl hits its opcode loop (and one or two other spots) we dispatch the handler. So several of the signal related things changed. Which probably explains why Linux did not segfault? But does not explain all the symptoms. If event is sitting in its own loop (not calling perl ops) then on 5.8 it needs to dispatch signal handlers. > >Rob Urban
