http://qs321.pair.com?node_id=1035082


in reply to Re^5: SIGHUP delivered on Windows
in thread SIGHUP delivered on Windows

Searching our code, I find exactly one place where we possibly invoke a SIGHUP handler, but I can't see how this could apply to my case. Maybe I'm overlooking something - could you have a look at the code below? This is the code we execute right after the start of our program, within an INIT block:

foreach my $signame (split(' ', $Config{sig_name})) { if ($signum) { $SIG{$signame} = $signame =~ /^KILL|STOP$/ ? 'IGNORE' # According to perldoc perlipc, they + can be ignored, but not trapped : sub { $SIG{$signame} = 'DEFAULT'; print {$_} "\n\nCaught signal $signame at ", timestampHMS, "\nCalled from:\n", callchai +n(3, 16), "\n\n" for (shutdown_log_handle(), *STDOUT); # We need a special handler for INT (i.e. cont +rol-C from command line), because # the default action would not call the END ha +ndlers and hence not unregister # the instance in the database. For other inte +rrupts, we deliberatrely do NOT # want it unregistered if ($signame eq 'INT') { print {$_} "Turning into graceful exit\n" for (shutdown_log_handle(), *STDOUT); exit; } else { kill($signum, $$); # proceed with norma +l handling of signal } }; } ++$signum; }
In our case, the logfiles only show the line saying a SIGHUP was received. As you can see, we *do* have a kill in this code, but it would simply rethrow the same signal.

However, there *is* some processing going on after we receive a signal. Before outputting the line to our logfile, we invoke for example the functions timestampHMS (to format the time in a nice way) and callchain (which formats a stacktrace using the Perl standard function caller</c>. While none of these functions explicitly send a signal, could it be that an exception occuring within this signal handler (or a second signal arriving by that time) could be translated somehow into a SIGHUP?

-- 
Ronald Fischer <ynnor@mm.st>

Replies are listed 'Best First'.
Re^7: SIGHUP delivered on Windows
by BrowserUk (Patriarch) on May 24, 2013 at 11:09 UTC
    could it be that an exception occuring within this signal handler (or a second signal arriving by that time) could be translated somehow into a SIGHUP?

    I cannot see how that could happen.

    Firstly, for you to get to the line where you do kill SIGHUP, $$, your process would have to have already received a SIGHUP; because you're just rethrowing it. But I am unaware of anything that would ever send you a SIGHUP.

    There is the vague possibility that another Perl process could be sending your process a SIGHUP; but as far as I'm aware, any attempt to do so would simply get translated into a SIGTERM.


    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.
    network sites:
      I agree with your reasoning. That's what I thought too.

      So for the time being, this has to remain a mystery. Thanks for taking the time to analyze my code.

      -- 
      Ronald Fischer <ynnor@mm.st>
        If you were running Cygwin Perl all your fav unix signals would work. But you claim to run ActivePerl so IDK what to say further.