Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re^2: Complex and reliable signal handling.

by sundialsvc4 (Monsignor)
on May 31, 2013 at 20:24 UTC ( #1036316=note: print w/ replies, xml ) Need Help??


in reply to Re: Complex and reliable signal handling.
in thread Complex and reliable signal handling.

... above is my post.   PM logged me out.

Also note that your termination code would need to consider, in a similar fashion, how to terminate gracefully:   if a thread is in the middle of creating a temporary file, it shouldn’t be shot-dead at that exact moment.

Edit:   Unfortunately, my original post appears to be wrong, see below, and I can’t strike it out because I don’t own it.


Comment on Re^2: Complex and reliable signal handling.
Re^3: Complex and reliable signal handling.
by BrowserUk (Pope) on May 31, 2013 at 20:45 UTC

    Read again. The OP didn't mention threads.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    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.
Re^3: Complex and reliable signal handling.
by vsespb (Hermit) on May 31, 2013 at 20:57 UTC
    Yep, I use fork().
Re^3: Complex and reliable signal handling.
by sundialsvc4 (Monsignor) on Jun 01, 2013 at 13:56 UTC

    I did “read it carefully,” thank you all very much.   I intended to use the term, “thread-safe,” loosely in this particular case, and in fact I did it inappropriately.

    The race that I hypothesize, does not concern resources being shared by threads in a single process-context, but rather, the resources that are being shared by all of the processes in the login-shell environment.   A statement as simple as $ENV{'FOOBAR'} = $ENV{'FOOBAR'} + 1; would exhibit this sort of race-condition conflict.

    It could also be that you should not exit() within the signal handler, but instead should set a flag which causes the main loop of the child process to end as-soon as-possible.   When this is done, then, no matter what the process was doing at the unpredictable instant in which the termination-signal arrived, you know that it will end at a predictable point and in a predictable state ... real soon now, but not at this very instant.

    Looking, now, more closely than I did before at the relevant perlguts, I see that JUMPENV_PUSH has to do with longjmp() state-saving.   Maybe there’s a hole there somewhere, and if so your task is to avoid it not to fix it.   By delaying the actual terminate to “real soon now” instead of “right now,” you’d avoid such a hole.

    This is specifically what I would do in the child:

    my $interrupted = 0; my @signals = qw/INT TERM USR2 HUP/; for my $sig (@signals) { $SIG{$sig} = sub { $interrupted = 1; } } #... then, throughout the code test for it ... #main loop: while (not $interrupted) { ... ... blah blah ... last if $interrupted; ... or ... exit(1) if $interrupted; }

    The only immediate “response to” the signal is to set a flag which indicates that a signal has been received.   The child’s processing-loop frequently tests this flag at strategic places, and busts-out of the processing loop gracefully.   The arrival of a signal should also knock the process out of various kinds of voluntary sleep, so that it will always be responded-to.   But it no longer matters precisely what the process was doing at the precise instant that the telephone rings.

    The parent-process should also explicitly wait-for children to terminate, before finally exiting itself, and before tearing-down any data structures that the children might depend on.   The second most-common place where applications sporadically fail, is when they are ending, because the parent jerks the rug out from under the children “sometimes.”

      I did “read it carefully,” thank you all very much....

      And then I respond to myself so you don't get notified of response

      Thank you for your response.
      It could also be that you should not exit() within the signal handler, but instead should set a flag which causes the main loop of the child process to end as-soon as-possible.
      When this is done, then, no matter what the process was doing at the unpredictable instant in which the termination-signal arrived, you know that it will end at a predictable point and in a predictable state
      Yes, that's often good idea to just set flag in signal handler.

      However, I was hoping that Perl is kinda high-level language, so there can be nothing unpredictible in termination in random point of program (with Safe-signals).

      Another problem, that my child processes have several possible places where they can spend significant amount of time. Inserting check for flag in all of those places is inconvenient.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1036316]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (6)
As of 2014-08-01 01:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (256 votes), past polls