in reply to Re: Coroner not helping - Perl5.8.4,threadsv1.03 and the case of myterious deaths
in thread Coroner not helping - Perl5.8.4,threadsv1.03 and the case of myterious deaths

Hi. Was out of action for a few days owing to sickness. Thanks for the tips. I smacked by forehead for not setting up warnings. ( I thought I had ) I do not know what happened after that. I was so fed up of the daemon dying that I just decided to look into the most tricky part. Consider this code which is part of one of the spawned threads

iprint " MAC: $mac : Contacting API......\n" if $debug > 1; # Wrap call to API with eval eval { local $SIG{ALRM} = sub { iprint "Network Delay) alarm ( $maxNetworkDelay) ; $ua = LWP::UserAgent->new( timeout => $maxNetworkDelay); $response = $ua->request( HTTP::Request->new(GET => $AuthURL +forMAC.$mac)); $respcon = $response->content; alarm(0); }; iprint " MAC: $mac $@" if $@;

( I know you had mentioned earlier that LWP::Simple would do the job but then I needed to look specifically into the RC codes in the response which LWP::Simple does not support.) 2 threads use the above code for 2 different URLS and the response is looked into for further course of action

I initially thought that the ALRM signal would be trapped in the eval block and the local signal handler would do the job. Apparently, the $maxNetworkDelay was being triggered when network delays occurs and that actually sends a signal to all threads. This was causing the death of the daemon.

By simply adding a $SIG{ALRM} = sub { return;) at the very top of the daemon before any thread definition I was able to recover. So when the ALRM is triggered all threads receieve them and return back to the state they were in earlier. MOdified code below with $SIG{ALRM} handler defined as common for all threads and local handler removed.

iprint " MAC: $mac : Contacting API......\n" if $debug > 1; # Wrap call to API with eval eval { $ua = LWP::UserAgent->new( timeout => $maxNetworkDelay); $response = $ua->request( HTTP::Request->new(GET => $AuthURL +forMAC.$mac)); $respcon = $response->content; }; iprint " MAC: $mac $@" if $@;

For the first time the daemon has run for 2 days without a problem. Did I know why I wrote the handler at the top? Partly yes, because I knew all threads were getting the signals in 5.8.4.

Do I know what is happening precisely? Definately not. Would appreciate your views on this

Replies are listed 'Best First'.
Re^3: Coroner not helping - Perl5.8.4,threadsv1.03 and the case of myterious deaths
by BrowserUk (Patriarch) on Oct 27, 2010 at 16:19 UTC
    Apparently, the $maxNetworkDelay was being triggered when network delays occurs and that actually sends a signal to all threads. This was causing the death of the daemon.

    This makes no sense to me at all. I've (briefly) scoured the LWP::UserAgent code, and can see nowhere that it raises a signal. Not as a result of a timeout, nor anything else.

    Did I know why I wrote the handler at the top? Partly yes, because I knew all threads were getting the signals in 5.8.4.

    Do I know what is happening precisely? Definately not. Would appreciate your views on this

    I've recently learned that this (frankly weird) behaviour of signals and threads is different on (at least one variant of) *nix, than it is on Windows. Even with recent versions of both Perl & threads.

    As such, whilst I hope my contributions so far have helped you to reaching a solution, I do not feel qualified to comment further on this. Sorry.


    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.