in reply to Re: Threads, bash, and networking
in thread Threads, bash, and networking

To be clearer, SIGALRM handlers inside the child thread are apparently never reached.

By that, I assume you mean that alarms raised in one thread are not caught in other threads.

Why would you expect that they would be? Signals don't cross fork boundaries, so why expect they might cross thread boundaries?

Remember, there is no parent-child relationship between threads, so if an alarm raised in one thread could be caught in a thread it spawned, it would also be caught by every other thread in the program.

There would simply be no way to reason about a system that meant that every thread received every signal raised in any other thread.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
RIP an inspiration; A true Folk's Guy

Replies are listed 'Best First'.
Re^3: Threads, bash, and networking
by juster (Friar) on Oct 23, 2010 at 06:20 UTC
    By that, I assume you mean that alarms raised in one thread are not caught in other threads.

    I mean if you comment out the top set_alarm() statement in my code, it will print "Alarm clock" and exit after 3 seconds. From this I am inferring that the created thread is successfully setting the alarm for 3 seconds. $SIG{ALRM} is set in the same created thread. The problem is the value of $SIG{ALRM} is never used. Instead the magic "Alarm clock" appears and terminates the program!

    This was also the first bullet-point of my conclusions:

    SIGALRM handlers inside threads are adorably useless. Put the SIGALRM handler in the main thread.

    So again, that wasn't my origin message. But since you mentioned it... alarms raised in the created thread were indeed caught by the main thread. In fact, according to my test program anyways, this is the only way alarm signals used in threads are functional at all.

    I would avoid using alarm signals in threads altogether. After trial and error, tweaking the code I posted, I have come to understand several nuances of alarm signals and threading. That is what I was trying to share. Hopefully from all the unpredictable behavior I have mentioned, readers can conclude that using alarm inside threads is not worth the headache.

[reply]
      alarms raised in the created thread were indeed caught by the main thread.

      Which versions of Perl & threads?

      I ask, because that is not what I see:

      perl -Mthreads 
-E"
$SIG{ALRM}=sub{die qq[main:Awooga!\n]}; 
async{
    local $SIG{ALRM} = sub{ die qq[thread:Awooga\n] }; 
    alarm 3; 
    sleep 5
}->detach; 
sleep 7;"

Thread 1 terminated abnormally: thread:Awooga

      [download]

      The alarm goes off, the thread-local signal handler catches it and executes and dies, the main thread then completes in the normal way.

[reply]
[d/l]
        When I run your code example, "main:Awooga!" is printed. When I comment out the top $SIG{ALRM} assignment, "Alarm clock" is printed. Here is the perl version for my linode: 
        [juster@artemis ~]$ perl -v

This is perl 5, version 12, subversion 1 (v5.12.1) built for i686-linu
+x-thread-multi

Copyright 1987-2010, Larry Wall
...

        [download]
        Here is the version for my macbook. This perl behaves identically to the above perl in the way I mentioned at the top of this note. 
        bash-3.2$ perl -v

This is perl, v5.10.0 built for darwin-thread-multi-2level
(with 2 registered patches, see perl -V for more detail)

Copyright 1987-2007, Larry Wall
...

        [download]
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom