Re: SIGHUP delivered on Windows

[BrowserUk]

I found indeed 1 case where SIGHUP seems to be generated.

I've never heard of SIGHUP ever being generated on windows, nor can I reproduce it.

#! perl -slw
use strict;
use Data::Dump qw[ pp ];
use Config;

$|++;

my @signames = split ' ', $Config{ sig_name };

eval qq[ \$SIG{ $signames[ $_ ] } = sub{ warn qq[SIG $_ received\n] };
+ ] for 1 .. 21;
pp \%SIG;

1 while sleep 1;

__END__
c:\test>sigtest 2>log
## typed ^C and then ^break and then closed the console
C:\test>type ..\log
do {
  my $a = {
    ABRT  => undef,
    ALRM  => sub { ... },
    BREAK => sub { ... },
    CHLD  => sub { ... },
    CLD   => 'fix',
    CONT  => undef,
    FPE   => sub { ... },
    HUP   => sub { ... },
    ILL   => sub { ... },
    INT   => sub { ... },
    KILL  => sub { ... },
    NUM05 => sub { ... },
    NUM06 => sub { ... },
    NUM07 => sub { ... },
    NUM10 => sub { ... },
    NUM12 => sub { ... },
    NUM16 => sub { ... },
    NUM17 => sub { ... },
    NUM18 => sub { ... },
    NUM19 => sub { ... },
    NUM24 => undef,
    PIPE  => sub { ... },
    QUIT  => 'fix',
    SEGV  => sub { ... },
    STOP  => undef,
    TERM  => sub { ... },
  };
  $a->{CLD} = $a->{CHLD};
  $a->{QUIT} = $a->{BREAK};
  $a;
}

SIG 2 received
SIG 21 received
^C

And if you trace the guts snippet you posted through, you'll find that do_raise() effectively return false for SIGCLD & SIGCHLD and true otherwise; and when it returns true, (as it will for the CTRL_CLOSE_EVENT|), sig_terminate() simple calls exit(sig) with sig == 1.

Basically, I don't think that there is any way perl on windows will ever receive or trap a SIGHUP, so any message you get to that effect must be a mistaken user message.

[rovf]

any message you get to that effect must be a mistaken user message.

What exactly is meant by "user message" here?

[BrowserUk]

Something not generated by Perl or the OS.

[rovf]

Sorry my ignorance, but I don't know much about Windows:

Would "something" fit, for instance, a process 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? In our case, the parent process would be Console2 (a sourceforge application which hosts several DOS Console session in parallel), so this might be a possible culprit...