I'm glad to see continued discussion. I managed to create what I believe to be the simplest test case for this behavior:
use strict; use warnings; use threads; use Thread::Semaphore; my $gag = new Thread::Semaphore(0); async { $gag->down; while (<>) { print; } }->detach; #close STDIN; # Comment this line for race-condition behavior $gag->up; my $value = async { return 1; }->join;
The proper behavior for this code should be to immediately return control to the OS. In its race-condition configuration under Win32, it will usually wait for one input and parrot it back and sometimes two inputs.
Based on your earlier post, I assume your 5.10 can function w/o the use of semaphores. I'll play with it a bit more to see if the addition of instrumentation to an independent log file affects the buffering behavior, but it seems like waiting for input on a shared file handle is blocking thread creation, i.e. what you said.
In reply to Re^7: threads on Windows
by kennethk
in thread threads on Windows
by kennethk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |