in reply to Re^3: Perl5.8.4 , threads - Killing the "async" kid
in thread Perl5.8.4 , threads - Killing the "async" kid

Hi again,

You wrote:
In a threaded process, if you install a signal handler using the 'normal mechanism' of %SIG, then that signal handler will only be called on the main thread. I assume--but haven't tested--this is the same for sigtrap.
Sorry about the unclear sentence. What I meant was this. In the code, the signal handler (sigtrap) , is defined at the very top before the thread definitions. This means, like all other functions and variables it duplicated for the threads created subsequently and each thread gets its own signal handler.
In the last 24 hours , I have had at least 3 instances where this appears as-is in the log file: 

 INT|ABRT|QUIT|TERM received....shutting down service.
 INT|ABRT|QUIT|TERM received....shutting down service.

[download]

2 of those 3 instances was when the main thread was sent a 

kill -15

[download]
and 1 was a reboot.

From this I assumed that each thread gets its own signal handler.
Or is that the signals are chained somehow and when the main thread is sent a TERM, the child gets them too?

Thanks for the tip on synchronising access to file handles. That is something I have not done at all. Maybe that is the reason why on some other boxes, the threads die a premature death after 3 minutes or so as opposed to the planned 24hr reboot cycle.

Replies are listed 'Best First'.
Re^5: Perl5.8.4 , threads - Killing the "async" kid
by BrowserUk (Patriarch) on Oct 12, 2010 at 13:42 UTC
    From this I assumed that each thread gets its own signal handler.

    Each thread may have the signal handler sub somewhere in its memory space, but it will only ever be called on the main thread. I cannot point you to any documentation that states this, but it is easily demonstrated.

    This creates 100 threads that wake up every 1/100th of a second. The main thread only wakes up once per second. I put the odds that the main thread (thread 0) will be in control at the given moment when you type ^C as 10,000 to 1 against, and yet no matter how many times you hit ^C, it will always be thread 0 that calls the signal handler: 

    #! perl -slw
use strict;
use threads ( stack_size => 4096 );


$SIG{ INT } = sub {
    warn threads->tid;
};

sub thread {
    1 while Win32::Sleep 10;
}

my @threads = map async( \&thread ), 1 .. 100;

1 while sleep 1;

__END__
C:\test>junk63
0 at C:\test\junk63.pl line 7.
0 at C:\test\junk63.pl line 7.
0 at C:\test\junk63.pl line 7.
0 at C:\test\junk63.pl line 7.
0 at C:\test\junk63.pl line 7.
0 at C:\test\junk63.pl line 7.

    [download]

    Try it for yourself; modify it to use sigtrap; send signals from other processes. It will always be thread 0 that responds. At least on recent perls, 5.8.9 and later. I'm fairly confident it should also be the case on earlier perls, but I haven't tried it.

    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.
[reply]
[d/l]
      Hi

      I can confirm that in Perl 5.8.4, threads v1.03 , each thread gets its own signal handler. This also explains my duplicate lines in the log file mentioned earlier in this topic.

[reply]
        This also explains my duplicate lines in the log file

        In a word; upgrade. At least threads & threads::shared. Preferably Perl also.

        But these things are often out of our control :(

        At a pinch; assuming that the quote means that the signal handler is being called separately on all the threads, add a check to only process the signal if you are the main thread. (Untested.): 

        sub handler {
    yield, return unless threads->tid == 0;
    ## Handle the signal
}

        [download]
        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.
[reply]
[d/l]

In Section Seekers of Perl Wisdom