in reply to Re^2: About the 5.10 'threads' scheduler
in thread About the 5.10 'threads' scheduler

That would make 'join()' non-interruptable.

Actually, there are many things that are not interuptable by signals, and most of them are unrelated to threading.For example, most IO (read, print, sys* accept etc.), sort, the regex engine etc.

This is especially true since the advent of "Safe signals" in 5.8.1. See the discussion under the description of the environment variable PERL_SIGNALS at the bottom of perlrun and the section "Deferred signals" in perlipc.

In place of that I am trying

Well, you could always move the joins into a thread:

my $done :shared = 0; async{ $_->join for @threads; $done = 1; }->detach; sleep 1 until $done; exit 0;

This will ensure that your main thread remains responsive to signals whilst the joins take place, and by detaching the join thread, it will clean up after itself without further intervention.

Of course, you could also use the cond_* calls in threads::shared instead of $done, but you still need a shared var for the signalling; the cond_* calls are the least well documented (and tested) part of threading; and the hardest to grasp, test and debug.

Besides which , cond_wait() is itself non-interuptable so that wouldn't help much.

Indeed, I only really mention cond_* for completeness. And because there are certain parties that frown upon my use of this "crude" (their word, I prefer "simple") signalling mechanism. In my experience, this simple signalling construct is far more reliable and far easier to debug than condition variables.


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.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."