[[email protected]: Event and non-Event signal handlers on Linux]
[email protected] (Joshua N Pritikin) Wed, 13 Aug 2003 09:37:05 +0530
| Newsgroups | perl.loop |
|---|---|
| Message-ID | <[email protected]> |
----- 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: G5xxqaZl8e6hUw5h68YDujSesAPy-184LCvLFz1BJvXhtDROUAB9cx@t-dialin.net 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. cheers, Rob Urban