> what your actual goals are
[download]

My actual goal is the implementation of a peer-to-peer framework. On top of this framework is a central executive node. Nodes are servers (database servers, analysis servers, collaboration servers etc.) and clients (desktop computers). The peers communicate with each other using messages (xml) and chat services. You see, events are the basis for the inter-node activities.

So, this is the reason for POE, the multitasking and networking framework for Perl (...) POE is a framework for cooperative, event driven multitasking in Perl. Other languages have similar frameworks. Python has Twisted. TCL has "the event loop".

> but it is not clear to me what you mean by: 
> "multiple users cann follow the output"? 
> Do you mean 'follow' as in tail -f?
[download]

Yes. Imagine, one user triggers a job from a client node. The central executive processes or possibly forwards the execution request , tracks and feeds back the output to the requesting node. Other nodes/ users are informed about the execution (utilizing chat services). Furthermore, the execution request has been enqueued in the central executive's message queue. Users can send read requests. If processing is already done, they simply receive the output. If processing is not done, yet, they see the same (following) output of the process.

> You want the script to launch a process and you 
> want the script to be able to receive that output, 
> but you also want the other "people", to be able 
> to monitor that output.

> How?
[download]

Exactly.

It is clear now, that the executors and output recipients reside on different network nodes.

> - Using concurrent copies of your script?
[download]

No.

> - By somehow attaching to 'the one copy' of 
>   your script and your script "broadcasting" the 
>   output to all listeners that attached?
[download]

Somehow. The central executive node actually triggers the request, receives the output and broadcasts the output.

> - By having the program write it's output directly 
>   (or via indirection) to a file and your script 
>   'tail-ing' that file after it has launched the 
>   process--so that other people can also monitor it 
>   using tail -f or whatever they choose?
[download]

Somehow. See the above comment.

> - Have your script launch the process and capture 
>   it's output and then, as well as doing whatever it 
>   needs to with it, also write it to a file so that 
>   other peope can monitor that file using tail or 
>   whatever?
[download]

This is exactly what I want to achive.

> Each of these approaches is possible, but which is 
> appropriate depends entirely upon what your 
> requirements are.
[download]

What is the best approach if you understand my goals?

That's a complex entity, rather beyond the scope of a "quick example". There are also some ambiguities in your description.

If processing is already done, they simply receive the output. If processing is not done, yet, they see the same (following) output of the process.

What if a read request is received for a process that has already started and produced half it's output? Does the new listener get everything that has already been sent to the file and any other listeners, or just that output the process produces after the request is received?

Anyway, here's how to use a thread to spawn a command and 'tee' it's output to a file, and retain a copy in memmory for your main thread to process at it convenience whilst also getting on with anything else it needs to do (like communicating with clients and monitoring queues):

#! perl -slw
use strict;
use threads qw[ yield async ];
use threads::shared;

my( $cmd, $file ) = @ARGV;
my $done : shared = 0;
my @lines : shared;

async {
    my $pid = open my $CMD, "$cmd |" or die "$cmd : $!";
    open my $fh, '>', $file or die "$file : $!";
    while( <$CMD> ) {
        chomp;
        print $fh $_;         ## output to the file
        push @lines, $_;    ## and push it to a shared array
    }
    $done = 1;
}->detach;

my $n = 0;
while( !$done ) {
    if( @lines ) {            ## lines to be processed
        print pop @lines;   ## process them
    }
    else {
        ## Else nothing to do but wait.
        yield;
    }
}
[download]

Whether that would work in conjunction with POE I'm not sure.

Personally, I would write the whole thing using threads, but that's rather more than your OP asked for, and would take a fair amount of effort.

---

Examine what is said, not who speaks.

Silence betokens consent.

Love the truth but pardon error.

> That's a complex entity
[download]

I agree

> some ambiguities in your description.
  (...)
> What if a read request is received for 
> a process that has already started and 
> produced half it's output?
[download]

Of cause, the user/ node who attached to a process which has not terminated, yet, after the process has already produced some output, the user first received the old output and next recieves the on-going output as it is produced by the continuing process.

Thank you very much for your Thread example. I am excited about its cooperation with POE on win32.