|The stupid question is the question not asked|
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?
Are there many things that can *only* be done via blocking syscalls in the main process?
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.
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:
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.