Threads and FileHandles

robblin has asked for the wisdom of the Perl Monks concerning the following question:

So I was wondering ... Say you have two threads

my $thread1 = new Thread \&Sub1;
my $thread2 = new Thread \&Sub2;
[download]

and Sub1 has something like:

select (LOCALFILEHANDLE);
sleep(5);
print "hi";
sleep(5);
select(STDOUT);
[download]

and Sub 2 has something like:

select (ANOTHERFILEHANDLE);
sleep(4);
print "By";
sleep(2);
select (YETANOTHERFILEHANDLE);
[download]

Which filehandle ends up selected, say, after the dispatched threads return? And furthermore, what happens when you do something funny in a thread (like undef $/) while another thread may be mid-file-read. I guess my question is, is IO thread-safe?

Comment on Threads and FileHandles Select or Download Code

Replies are listed 'Best First'.
Re: Threads and FileHandles by Dog and Pony (Priest) on Apr 11, 2002 at 08:38 UTC
When you are manipulating the same data in two places at the same time like that, all bets are usually off. 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. `my @array = <FH>;` [download] Would probably be just fine, even if the `undef` call comes in the middle of the read. `while( $_ = <FH> ) { ... }` [download] 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. :) 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 You have moved into a dark place. It is pitch black. You are likely to be eaten by a grue.	[reply] [d/l] [select]
Looks like it might be safe... by RMGir (Prior) on Apr 11, 2002 at 12:58 UTC
This is all based off of reading 5.7.4 src. YMMV Assuming pp_select is what implements select (big assumption, but that looks like what this code does) I think the select operation probably is threadsafe. The default output location looks like it's PL_defoutgv, which is a #define for a component of aTHX, which I _believe_ is thread local. Since pp_print also uses the same output dest, I think his whole script will work as expected, assuming the sleep "sleeps" the thread and not the process... -- Mike Edit: Added caveat about sleep	[reply]
Re: Threads and FileHandles by Elian (Parson) on Apr 11, 2002 at 18:14 UTC
You're OK there--the default filehandle is a per-thread variable, so what you do in one thread doesn't affect any other. (As are most of the magic globals, like $/, $\, and $!)	[reply]