"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.
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. 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?
Thanks for all the research,
Tom Wyant
This communication is for use by the intended recipient and contains
information that may be privileged, confidential or copyrighted under
applicable law. If you are not the intended recipient, you are hereby
formally notified that any use, copying or distribution of this e-mail,
in whole or in part, is strictly prohibited. Please notify the sender
by return e-mail and delete this e-mail from your system. Unless
explicitly and conspicuously designated as "E-Contract Intended",
this e-mail does not constitute a contract offer, a contract amendment,
or an acceptance of a contract offer. This e-mail does not constitute
a consent to the use of sender's contact information for direct marketing
purposes or for transfers of data to third parties.
Francais Deutsch Italiano Espanol Portugues Japanese Chinese Korean
http://www.DuPont.com/corp/email_disclaimer.html
