----- 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.
cheers,
Rob Urban
