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

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.

Replies are listed 'Best First'.
Re^8: The implementation of SIGHUP in Win32 Perl
by klaten (Novice) on Sep 11, 2013 at 19:56 UTC

    Thank you so much for taking the time of day with me. Your posts are entertaining and enlightening. You wrote "I break dragons every day, they are much better for transporation than horses," that really made me smile, you really are quite the "code warrior." You also wrote, "if you haven't figured it out yet, I'm a p5per." That explains the scorch marks on your dragon shield (smiling). Thank you. Folks like you keep Perl5 fun for folks like me.

    I think we have some philosophical differences about Perl5 and that's fine, it's part of what makes life so interesting. I'm (like many folks these days) "financially distressed" (smiling), I mention that because I think it has changed the way I think of many things including Perl5. When you're poor, but resourceful (I like to think of myself that way), you look at individual things around you and see, not its age and specks of rust, but instead, its utility. Perl5 is still the "Swiss army chainsaw" to me. I expect there will be scant few problems in this life I can't solve with Perl and C (world peace, anyone).

    Much of the Perl5 community seems dispirited these days. I read comments similar to "many people with decision making power see Perl 5 as being in "maintenance mode" for legacy code, and back-compat is above all else," in a lot of places and it seems tinged with regret. Well, I certainly don't have any "decision making power," but I like the idea of Perl5 being in "maintenance mode." You could probably say the same thing of the "C" language; wouldn't it be cool if Perl5 because the dynamic language equivalent of "C"?

    When I wrote:

    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?

    and

    Are there many things that can *only* be done via blocking syscalls in the main process?

    You replied:

    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.

    and

    Your piped open will block on windows when there is no data from the child process in the pipe.

    Sure, I get that. But, now that I have these "fakey," "pseudo," "signal-message hybrid things" in my toolbox, I could:

    1. Send a signal from child to parent to indicate I have a line to read,
    2. Read the line in the parent,
    3. Send a signal from parent to child to say "got it, send me another."

    Goodbye blocking, hello crude but effective flow control. I love TIMTOWTDI, problems usually reduce themselves down to finding the "appropriate" technique to apply.

    One of my favorite Perl books is Mastering Perl/Tk because they took the shortcomings of Win32 and found workarounds. No fileevent? No problem, let's try memory-mapped files, instead. Cool! I wish the Perl community would stop feeling sorry for itself, embrace TIMTOWTDI enthusiastically, and help us "pikers" use some of these more obscure "attachments" to the "chainsaw" to cut through our own problems. But come to think of it, that's what PerlMonks is, isn't it? I have no Python/Ruby envy at all, they'll have to pry Perl5 from my "cold, dead, hands"! Cheer up, everybody. Perl5 is still great!

    One of the craziest things to me about modern society is the notion of "obsolescence." I find it insane that folks toss away perfectly good smartphones simply because they can't talk to Siri. Well, Perl5 may not be able to talk to Siri (yet!), but it can do just about anything else most of us "mere mortals" need to do. Please keep slaying dragons, there are plenty of us who happen to like living in this "village" and need folks like you to keep us safe there.

[reply]
Re^8: The implementation of SIGHUP in Win32 Perl (non-synchronous IO )
by Anonymous Monk on Sep 11, 2013 at 22:21 UTC

    I've never seen any evidence of anyone using the native Win32 API (XS) in Perl for non-synchronous IO except me.

    Where can I see that?

[reply]

      See Named Pipe Server Using Completion Routines for an example of using asynchrounous IO on Windows.

      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.
[reply]
        But that is in C, the Anon I assume, and I was referring to XS (or Inline::C) code that would do that. ReadFileEx doesn't exist on CPAN, http://grep.cpan.me/?q=ReadFileEx. I do use ReadFileEx in proprietary XS code. Of course you can argue with Win32::API anything you do in C you can do in Perl, BUT, keeping a char * buffer from an SV allocated during the async operation, while Perl is dealing with other events/things to do, with an event loop, is complicated from pure perl. A pack('P' doesn't guarantee the char * will remain live when the current sub returns, or the next statement boundary.
[reply]
[d/l]

In Section Meditations