Re^7: SIGHUP delivered on Windows

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:

Comment on Re^7: SIGHUP delivered on Windows Download Code

Replies are listed 'Best First'.
Re^8: SIGHUP delivered on Windows by rovf (Priest) on May 24, 2013 at 11:33 UTC
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>	[reply] [d/l]
Re^9: SIGHUP delivered on Windows by bulk88 (Priest) on May 25, 2013 at 01:14 UTC
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.	[reply]
Re^10: SIGHUP delivered on Windows by rovf (Priest) on May 28, 2013 at 14:54 UTC
How true ..... :-( -- Ronald Fischer <ynnor@mm.st>	[reply] [d/l]


more useful options
	PerlMonks