You'll need to:

• understand the non-shared cloning behaviour
• understand the shared-var clobbering behaviour
• understand where the magic will/won't hold up

I mostly use Thread::Queue to communicate between a reusable pool of threads. I try not to use shared variables (so I don't have to reason about what is/isn't shared). I make sure not to allocate *anything* I don't have to in the "parent" thread.

There certainly are still some problems. There's no other option on Win32; fork() there is an emulation using iThreads which breaks other things (so you shouldn't use it).

I'm sure others will have war stories... I've got what I needed to done without too many problems... mostly working around cloning and file-handle DESTROY issues.

-David

• POE Cookbook watching logs
• POE Cookbook tail following web server
• POE Cookbook IRC logfile tailing

If you need to constantly monitor the file tail results, you could use threads, but there are alot of caveats to watch for when using threads. Many times, threads need to be created before any other object code is called(due to non-threadsafe objects), so you may not be able to just use threads any way you want. Threads work well if properly setup for the situation, but you show use the SuperSearch box here and search for all the previous posts on threads. See Why use threads over processes, or why use processes over threads?

forking is probably a better choice

But only if you are on a platform that supports a native fork. Otherwise you;re just using threads but without the control and a whole different set of caveats in addition to those of threads.

---

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

For simplicity, does it get much easier? Just supply the name of the directory containing the files and you're off. ^C to end it.

#! perl -slw
use strict;
use threads;
use threads::shared;
use File::Tail;

my $quit :shared = 0;
$SIG{ INT } = sub{
    $quit = 1;
    warn 'Quiting';
};


sub thread {
    my $tid = threads->self->tid;
    my $name = shift;
    my $file = File::Tail->new( $name );
    while( not $quit and defined( my $line = $file->read ) ) {
        print "$tid ($name) '$line'";
    }
}

$_->join for map{
    threads->create( \&thread, $_ )
} glob $ARGV[ 0 ];
[download]

For stability, make sure you use the latest version of Perl (5.8.8), threads, and threads::shared.

If you test your solution and are happy with it before you put it into production, then it should be stable. As with pretty much any feature of perl, it is possible you will encounter a bug once in production, but if you've stayed within the limitations of the features you use, and tested thoroughly, you'd be unlucky to do so.

However, if you do use threads and need to process the content in one single place, consider isolating each File::Tail in its own thread, and (as others have mentioned) use Thread::Queue to pass values to the thread processing the data.

/J

Interesting points w.r.t select on Win32 were raised in Re^6: How to make sysread timeout.

I've had no issue using IO::Select with INET sockets on Win32, but I'd bet BrowserUK is spot on about the file-handles issue on that platform.

-David

Cheers
Chris