Steve Hay <[EMAIL PROTECTED]> writes:
>>
>Good question, and in trying to write to equivalent C program I've
>realised that Win32 doesn't actually have kill() in its CRT!
>
>win32/win32.c handles it in win32_kill() like this:
>
> switch(sig) {
> case 0:
> /* "Does process exist?" use of kill */
> retval = 0;
> break;
> case 2:
> if (GenerateConsoleCtrlEvent(CTRL_C_EVENT,pid))
> retval = 0;
> break;
> case SIGBREAK:
> case SIGTERM:
> if (GenerateConsoleCtrlEvent(CTRL_BREAK_EVENT,pid))
> retval = 0;
> break;
> default: /* For now be backwards compatible with perl5.6 */
> case 9:
> if (TerminateProcess(hProcess, sig))
> retval = 0;
> break;
> }
>
>which I guess mostly explains the behaviour I reported:
And at least part of that coding was mine.
I was trying to cleanup Win32's signals/events at the time
and then (possibly as a result of this work!) my NT partition on that
machine went AWOL and I lost enthusiasm.
Corrupting partitions aside, I think there is still scope for
Win32 to do better at signals - particularly between a perl parent
and its pseudo-fork()ed children.
>GenerateConsoleCtrlEvent() causes the control handler functions of
>processes in the target group to be called, so they are free to exit
>with whatever status they choose in response to such events.
>
>So INT, TERM and BREAK are simply documented wrongly in perlport. I'm
>not sure why QUIT and CLD didn't work right, though.
>
>
>
>------------------------------------------------
>Radan Computational Ltd.
>
>The information contained in this message and any files transmitted with it
>are confidential and intended for the addressee(s) only. If you have received
>this message in error or there are any problems, please notify the sender
>immediately. The unauthorized use, disclosure, copying or alteration of this
>message is strictly forbidden. Note that any views or opinions presented in
>this email are solely those of the author and do not necessarily represent
>those of Radan Computational Ltd. The recipient(s) of this message should
>check it and any attached files for viruses: Radan Computational will accept
>no liability for any damage caused by any virus transmitted by this email.
