http://qs1969.pair.com?node_id=1034579


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

Would "something" fit, for instance, a process [ Console2 ] which started our Perl process, and then delivered a Windows Message to this process, and Perl, not knowing what to do with this message, invokes the signal handler established for SIGHUP?

No. I downloaded the source for console2 and the string "SIGHUP" does not appear anywhere in it, so your log message does not come from that.

As I said, I don't believe there is any way for a perl process to ever invoke a SIGHUP handler. Which only leaves your perl script to be the source of that log message in response to some stimulus other than a sighup. (ie. user error)


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.

Replies are listed 'Best First'.
Re^6: SIGHUP delivered on Windows
by rovf (Priest) on May 24, 2013 at 07:33 UTC
    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>
      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>