I'd assume that perls internal functions are threadsafe in themselves - what would be the point to build with threads at all otherwise? So the selects wouldn't interrupt or disturb each other. Even without that, you probably would get the expected result anyways, STDOUT ends up being selected last. But you can in no way count on it.
As for the undef $/, I would guess that the same rules apply. Perl internals being thread-safe, it would depend on what you mean by reading.
Would probably be just fine, even if the undef call comes in the middle of the read.my @array = <FH>;
On the other hand, probably would suddenly slurp the rest of the file in - this is multiple IO operations after all. However, I might of course be wrong. :)while( $_ = <FH> ) { ... }
That said, you simply do not write threaded code like that - unless you are collecting statistics for chaotic behaviour, standard deviations or something.
Usually you want to stay away from accessing the same data as much as possible, and using threads to do stuff simultaneously, all with their own separate data. But of course, most implementations demand that you share some data, at some point... for instance, a chat engine would be pretty boring if all users wrote to their own separate chatroom. :) This is where locking and controlling access comes in. Take a look at perlthrtut for ways to do that, with semaphore locking on variables, or subroutine synchronization.
Most of the above is void if perl built-in functions are not thread safe. But if you can't trust your perl, then who can you trust? *Grin*
In reply to Re: Threads and FileHandles
by Dog and Pony
in thread Threads and FileHandles
by robblin
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |