Re^3: The implementation of SIGHUP in Win32 Perl

[bulk88]

IMHO, the key problem with the current implementation is that it seems to assume the console control handler code is being called as a callback (which is what I believe happens in Windows XP), when actually the console control handler code (in Windows Vista and later) is being called from another thread being started by Windows (see note 1, below). This control handler code then triggers Perl's signal handling code, from the other thread. The signal handling code in the Perl program will be running at the same time the Perl program is. I'd be very surprised if Perl were designed to do that!

It is always executed in a separate thread in every NT OS, not just Vista. DOS Win I can't speak about, but it might have actually interrupted the main thread since in old MSDN docs for the CRT, on DOS Win ONLT, there a quite a number of more CRT signals that are catchable than on MS CRT on NT. The multi-threading of the console event dispatch often can cause assert fails and crashes from Perl if Perl is in a 100% CPU usage loop on a multi core machine. I've filed tickets about it in Perl RT. Signals block all other execution I think on Unix. The console event thing runs in a separate thread without stopping the first thread. The runloop in the main thread will get a NULL and exit quickly if the console event thread hasn't gotten to the exit() yet in most cases, or the main thread is in blocking IO and its not a problem for the child thread to reenter the same interp and do perl global destruction.

My idea for the fix would be to do a SetThreadContext (C debugger-ish stuff) see http://msdn.microsoft.com/en-us/library/windows/desktop/ms680632%28v=vs.85%29.aspx, and try to implement it unix style with the event interrupting execution and executing in the context of the parent thread. NT does have its own implementation of Unix signals called asynchronous procedure calls (APCs) see http://msdn.microsoft.com/en-us/library/windows/desktop/ms681951%28v=vs.85%29.aspx, but if you read about them, they only run when you, the process, requests to rundown the APC queue, so they are always predictable unlike Unix signals (an intentional design), but most syscalls typical Win32 processes are never the "alertable" kind, and if you have a single DLL that you didn't write yourself in the process, you are probably screwed cuz that DLL will be making non-alertable syscalls. If someone really wanted to (space elevator fantasy here), they could DLL hook kernel32, or SSDT hook it, and add APC dispatching to syscalls that dont run APCs. The syscalls would have to be retried by the layer/shim when they fail because APCs ran. The kernel32 and ntdll alertable syscalls dont do that for you.