[Pdx-pm] Q about ithreads && signals

Kyle Hayes kyle_hayes at speakeasy.net
Sun Nov 17 13:50:54 CST 2002

On Saturday 16 November 2002 21:29, Joshua Hoblitt wrote:
> Tom,
> The eval block is there in some kind of ill concieved attempt to keep
> the signal from propagating.  The local is a left over from perlipc and
> I was also hoping that it would limit the signal.
> Your right that '$SIG{ALRM} = \&get_doc' would save a function call. 
> It's there because I had a print statement included for debugging.
> This is the result of code being mangled serveral times in trying to
> track the problem down.
> This is a quote form perlthrtut:
>     "Similarly, mixing signals and threads should not be
>      attempted.  Implementations are platform-dependent, and even
>      the POSIX semantics may not be what you expect (and Perl
>      doesn't even give you the full POSIX API)."
> Maybe I should try setting $SIG{ALARM} outside the eval block... hmm...

In C under the current Linux implementation, threads and signals are weird 
and not POSIX compliant.

I haven't had the chance to use ithreads yet, but in C, something as 
"simple" as SIGALARM may not even go to the right thread.

Rather than SIGALARM, use the queuing code that the new threading provides.  
That'll probably be closer to what you want if I've understood what you 
are trying to do...

Believe the manual when it talks about threads  and signals!


More information about the Pdx-pm-list mailing list