[Pdx-pm] Q about ithreads && signals

[Joshua Hoblitt]

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...

-J

--
"Suppose you were an idiot. And suppose you were a member of Congress. But I repeat myself." -- Mark Twain

On Sat, 16 Nov 2002, Tom Phoenix wrote:

> On Sat, 16 Nov 2002, Joshua Hoblitt wrote:
>
> >         eval {
> >                 local $SIG{ALRM} = sub { &get_doc };
> >                 ualarm 10_000_000, 10_000_000;
> >                 while(1) { sleep; }
> >         };
>
> I'm not sure why you're using the eval block there. If you don't want to
> check $@ to find out why it exited, that can be okay; but you should
> probably add a comment saying why you don't care that you just trapped a
> fatal error. (Of course, since no code follows that eval (does it?),
> you've simply made the fatal error silent. :-)
>
> And maybe I'm just too allergy-plagued and -medicated tonight to see
> clearly. Is there some advantage to using that first line inside the eval
> over this simpler one?
>
> 	local $SIG{ALRM} = \&get_doc;
>
> For that matter, why local?
>
> Have you tried throwing some debugging output statements into this? Like
> this one...
>
>     warn "Entered ALRM handler: " . localtime;
>
> With a few of those, you may be able to tell whether your handler is being
> called when you think it is, among other things. And when it's returning,
> too:
>
>     warn "Returning from ALRM handler: " . localtime;
>
> Again, I'm on medication tonight, so I shouldn't be operating heavy
> machinery or thread-bearing code. But what happens if your handler takes
> more than ten seconds to return?
>
> Good luck with it!
>
> --Tom Phoenix
>
>