http://www.perlmonks.org?node_id=1052266


in reply to Re^3: The implementation of SIGHUP in Win32 Perl
in thread The implementation of SIGHUP in Win32 Perl

It is always executed in a separate thread in every NT OS, not just Vista.

Ah, that's good to know, thanks.

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.

That makes sense. So basically we were all just lucky that the other two event triggered signals, SIGINT and SIGBREAK worked. Which validated the advice "don't do too much in your signal handler," because the more you did (or the busier your machine), the more likely you would be to run into a thread conflict causing a crash.

I looked at the thread context and APC stuff, but both those topics are over my head, I'm afraid. All I was thinking about was to simply "re-throw" the event signals (by "posting" a WM_USER_KILL message from the message handling thread appropriate for the signal to "handle") instead of calling back into Perl. What I wonder about, and perhaps you can help with is this side of the win32.c signal code:

case WM_USER_KILL: {
    /* We use WM_USER_KILL to fake kill() with other signals */
    int sig = (int)wParam;
    if (do_raise(aTHX_ sig))
        sig_terminate(aTHX_ sig);
    return 1;
}

[download]

Do you know of any issues with that side of the code? I was thinking it would trigger the $SIG{ 'HUP' } in the same thread as the perl interpreter. If that's true, then what I wanted to do might have a chance of working. Anyway, thanks for the feedback.

Replies are listed 'Best First'.
Re^5: The implementation of SIGHUP in Win32 Perl
by bulk88 (Priest) on Sep 04, 2013 at 19:43 UTC
    The problem with just "sending" a message to the main thread is, what if the main thread is in a blocking syscall, directly from Perl lang or through some XS-ed C library? How do you ensure the responsiveness of the fake-signal if the main thread is blocked in the kernel?

    I did once take a C debugger, when the console event hit the 2nd thread, I paused the main thread, let the 2nd thread run to completion and shut down Perl interp struct, and I dont remember (and cant research it ATM, normally I would research it for you but im not at my devel machine this post is from memory), but I think the 2nd thread ended the 2nd thread, I then ran the 1st main thread, now with an almost uninitialized interp struct, and it very quickly called C's exit() and that was it. I also fixed a race condition maybe a year ago between sending a kill 9 from a parent fork thread/fake process to the child fork thread/fake process, where the child thread was still initializing itself in user mode kernel32/ntdll, before calling any process specific code, and when killing the child thread, it would leave the DLL loader lock, locked, by the now gone 2nd thread, when the perl interp trys to exit, the DLL loader from the main thread tried to aquire the DLL loader lock and hung forever.

    I've also dispatched events from multi threaded pure C code, using Perl's win32 fake signals dispatch code by setting a 1 in some array in the perl interp struct which corresponds to one of the 2 dozen signals names on Win32 perl, then setting a global flag that there is a pending signal for the interp to dispatch to the perl lang level, and on PERL_ASYNC_CHECK() the fake signal was dispatched, which eventually called a Perl lang sig handler which then called XS code which pulled events off the pure C's event queue. I think I used signal NUM05.

    You should ask on the p5p mailing list. You will get more C/interp internal knowledgeable eyes than on PerlMonks. The p5p IRC room has less eyes and less Win32 eyes. Since there arent very many p5p win32 guys. You probably want an answer from steve hay, tony cook, or jan dubois. None of them are active at PM. Also use git blame, for example http://perl5.git.perl.org/perl.git/blame/HEAD:/win32/win32.c and look at the evolution of the code you are wondering about.
[reply]

      Wow, that's *seriously* deep stuff, you've attempted! I don't think I want to go that deeply into the forest. The quote, "Do not meddle in the affairs of dragons, for you are crunchy and taste good with ketchup" would seem to apply to me regarding the things you tried. Your paragraph beginning with "I did once take a C debugger, . . .," made me smile because it sounded like the beginning of one of the stories an Arthurian knight might have spun. Powerful stuff, nonetheless.

      The next paragraph about the dispatch of events from perked my interest because I can see how that could work to solve the issues you raised in the first paragraph. I'm going to return to that first paragraph because I think it's the most interesting of all.

      Thank you for the advice about the p5p mailing list. I've come to the conclusion that I need to craft my own console control handler in XS and install it on top of Perl's, ensure that it works to my satisfaction, and then I'll be able to make a more acceptable contribution. It sounds like they may be a great source of wisdom in that endeavor. And tracking the evolution of win32.c actually sounds like fun! So I know I'll do that. Thank you, again.

      Now back to that first paragraph (written with a smile)! You wrote:

      How do you ensure the responsiveness of the fake-signal if the main thread is blocked in the kernel?

      One possible answer might be, "you don't." Your other question holds the key to that idea.

      The problem with just "sending" a message to the main thread is, what if the main thread is in a blocking syscall, directly from Perl lang or through some XS-ed C library?

      Isn't Perl5 evolving in that direction, anyway? Aren't those restrictions similar to the limitations of "safe signals"? Are there many things that can *only* be done via blocking syscalls in the main process? It reminds me of the classic "doctor-patient joke:"

      Doctor: Please tell me about your problem.
      Patient: It hurts when I do this.
      Doctor: So don't do that!

      In Perl5 we have many tools to allow the use of multiple processes (in Windows, Linux, and the other platforms as well) to handle the types of things most people would want to use blocking syscalls for anyway. With simple IPC techniques like piped opens and "safe signals" why bother with complex, flawed, and potentially crash prone things like full POSIX signals anyway? I can see that you have the skills and moxie to attack that problem, but I can't help but wonder whether or not the better way is simply to accept Perl5 as a wonderful single-threaded C program (perhaps the greatest, ever) and maybe leave those more complex issues to the Perl6 people.

[reply]

        Now back to that first paragraph (written with a smile)! You wrote:

        How do you ensure the responsiveness of the fake-signal if the main thread is blocked in the kernel?

        One possible answer might be, "you don't." Your other question holds the key to that idea.

        Then you dont have "signals" at all. die "signals not implemented";
        The problem with just "sending" a message to the main thread is, what if the main thread is in a blocking syscall, directly from Perl lang or through some XS-ed C library?

        Isn't Perl5 evolving in that direction, anyway? Aren't those restrictions similar to the limitations of "safe signals"? Are there many things that can *only* be done via blocking syscalls in the main process?

        Evolving? IMO Perl 5 doesn't evolve. Many people with decision making power see Perl 5 as being in "maintenance mode" for legacy code, and back-compat is above all else.

        What are safe signals? That is a term that Perl 5 created to mean a queue and deferred execution of signals at safe points. It isn't an OS feature. Non-blocking and async IO support in the core language is hit or miss on all the different platforms that Perl runs on. On Win32 Perl, sockets are the only non-synchronous IO. I've never seen any evidence of anyone using the native Win32 API (XS) in Perl for non-synchronous IO except me. The XS code for GUI toolkits on Perl sometimes disable (Glib) with a comment in the code saying to use "native" Perl IO instead. In other cases the toolkits (QT) do blocking IO in an fresh OS thread, which is incompatible with Perl's architecture since OS specific non-syncronous IO is so hit or miss that the toolkit authors gave on it. Or, its not implemented in the toolkit on windows, Perl Tk. Or not implemented at all, (WX).

        In Perl5 we have many tools to allow the use of multiple processes (in Windows, Linux, and the other platforms as well) to handle the types of things most people would want to use blocking syscalls for anyway. With simple IPC techniques like piped opens and "safe signals" why bother with complex, flawed, and potentially crash prone things like full POSIX signals anyway? I can see that you have the skills and moxie to attack that problem, but I can't help but wonder whether or not the better way is simply to accept Perl5 as a wonderful single-threaded C program (perhaps the greatest, ever) and maybe leave those more complex issues to the Perl6 people.

        Perl 6 is not Perl 5, and never claimed to be syntax compatible. Is C# the successor of C++? Your piped open will block on windows when there is no data from the child process in the pipe.
[reply]
[d/l]

In Section Meditations