At 10:36 AM -0500 1/17/05, Thomas R Wyant_III wrote:
>"Craig A. Berry" <[EMAIL PROTECTED]> wrote on 01/17/2005 12:24:20 AM:
>
><snip />
>
>> Well, of course it's not that simple. What was I thinking? :-( A
>> bit more analysis shows that where it gets stuck is in the parent,
>> which is not doing one of our pipe $QIOs at AST level, but is instead
>> sitting there in a plain old fgetc() waiting for the child to write
>> something to it.
>
><snip />
>
>> So the first time a read completes after a signal has fired, the
>> signal gets processed. Clearly we can't put anything inside of
>> fgetc() to check for Perl's pending signals. The only curiosity now
>> is what's happening on platforms where the parent is reading but the
>> child is not writing -- how are we checking for signals in that case?
>
>Dunno. I _do_ know that the following case also "works" (meaning, SIGALRM
>gets delivered when you would hope it does):
>Perl v5.8.1-RC3 under Darwin 7.7 (I think).
>
>This is the perl that comes with Mac OS 10.3, and I haven't gotten around
>to upgrading. The darwin 7.7 is from memory, and I think makes it Mac OS
>10.3.7.
I've confirmed the same results with bleadperl on Mac OS X 10.3.7.
>This begins to feel like a restriction, since you have tried other VMSes
>and gotten the same behaviour, and have traced the problem into fgetc.
Yes, a restriction we apparently share with Windows.
>The
>thing is, defining PERL_SIGNALS to "unsafe" appears to restore the old
>behaviour. Is the old behaviour to execute the signal code in AST mode?
The old behavior is to let the C signals happen whenever they feel
like. The C library is expected to take care of itself so it doesn't
get into trouble, but this poses a problem for Perl, which is in
essence a type of virtual machine. Just as it would be bad news for
a hardware machine to get interrupted in the middle of an
instruction, leaving the processor in an inconsistent state, it's bad
news when a Perl opcode gets interrupted after it has started but
before it has finished. So the default is now to defer signals until
we are in between operations that need to be atomic.
If I can figure out what the unixes are doing and if it's something
we can do without causing other problems, I may yet solve this. But
I may not, and almost certainly won't get to it quickly. So I'm
afraid you are stuck with one workaround or another for now.
BTW, a better workaround than setting PERL_SIGNALS in your
environment would be to replace your kill sub with the following,
which I came across in the documentation while digging into this:
use POSIX;
sigaction SIGALRM, new POSIX::SigAction sub {
kill KILL => $pid;
}
--
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
