in reply to About the 5.10 'threads' scheduler

A Win32 Perspective:

This should be simple if I can find the correct "FM" to "RT"; or a link to such.

If you find one, please come back and post a link. I'd like to read it also.

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."

Replies are listed 'Best First'.
Re^2: About the 5.10 'threads' scheduler
by Wiggins (Hermit) on Sep 26, 2008 at 16:41 UTC
    These are good answers, thank you...

    On the subjects of signals, my intent is to be able to use signals to 'signal' my daemon app to do a clean shutdown; or for logrotate to notify that the logfile I am watching has been rotated.

    My testing has shown that once my main thread drops into a 'join', signals are no longer processed. That would make 'join()' non-interruptable. In place of that I am trying: 

     #done starting all threads

 while (!$cleanShutDown) { # set in SIGHUP handler
    sleep 30;  # which is interupted by a signal
 }
 $logmon -> join();
 ... #more joins
 exit 0;

    [download]
[reply]
[d/l]
      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;

      [download]

      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.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom