First of all, thwanks for your help. I **think** this is what I need.

Now you'll see what a novice I am

When I use perldoc as you've descibed, how do I view this:

Make sure you read the deadlock warnings in its documentation, though (see L<IPC::Open2>).

Also, How do I signal that I am done writting to the pipe and I would like prog.pl to proces the data and print it's output to Reader?

thanks, me

Anytime you see "see <Module::Name::Here>" you can do perldoc Module::Name::Here to see the documentation, provided the module is installed on your host.

In terms of finishing with the application, if you end up going with the IPC::Open[23] methodology you would do something ala

# assuming READ, and WRITE are the reader and writer FHs
# and $pid is the pid of the process spawned
close(READ);
close(WRITE);

waitpid $pid, 0;

# or if you used FileHandle objects or autovivified scalars
close($read);
close($write);

waitpid $pid, 0;
[download]

After rereading your post, I noticed I didn't answer the right question. How does the program presently know you are done writing? Is there some sentinel value? Do you pass a <CTRL> + d? You will simply do the same at the end of your write loop. Alternately if you don't have that functionality presently in the prog, you could add it and then make use of it :).

use perl;

"When I use perldoc as you've descibed, how do I view this: Make sure you read the deadlock warnings in its documentation, though (see L<IPC::Open2>). "

What they mean is to man IPC::Open2 or look at the IPC::Open2 library docs however you view library docs on your system. That whole "L<...>" is a way of doing a link to another data source in perl POD documentation... but it seems to be either broken or broken in your POD-viewer.

Oh, and as for signalling that you are done writing, etc... that's what they're talking about in the whole deadlock-prevention business. The issue is, you need to make it completely clear to each process which one is writing and which one is reading at any given time. If there is any ambiguity, and both process think that they should be reading or both think they should be writing... then you're deadlocked.

A simple means of avoiding this (if it fits your problem) is to provide "framing data" in your streams. This is sort of akin to saying "over" on a walky-talky. You mean "I'm done writing, it's your turn to write". The way you do that is you can isolate some string that should never appear in your data, and you send that string as a magical token over your stream as such a signal.

If there is no way to determine a token which should never appear in your data, then you would need to encapsulate your data somehow. A simple example is to pick some magical character... like let's say a newline character ("\n") and an escape character like a backslash. Then in the program writing the data, you turn all newlines into \n's and all \'s into \\'s, and in the reading program you do the opposite. Now the actual newline character won't appear anywhere in your data, and you can use it to "frame" your data.

# writer
$data =~ s/\\/\\\\/g;
$data =~ s/\n/\\/g;
print PIPE $data,"\n";

# reader
$/ = "\n";
$data = <PIPE>;
chomp $data;
$data =~ s/\\n/\n/g;
$data =~ s/\\\\/\\/g;
[download]

Of course, that example assumes that you can easily establish a protocol (by that I mean simply a set of rules) for which process should be reading and which process should be writing at any given time. If you need to go beyond that, then you're really opening up a can of worms and should look into some more robust frameworks for IPC (inter-process-communication).

------------
:Wq
Not an editor command: Wq

If you only have one batch of data to send to your child process, you can signal that you're done by just closing the write filehandle. The child process will see this as EOF in its STDIN, but will still be able to write to STDOUT just fine. Of course, once you've done this, you can't send any more data to the child process.

Here's a short example:

#!/usr/bin/perl -w

# This is t6

use strict;
use IPC::Open2;

open2(\*READ,\*WRITE,'/tmp/t6b')
  or die "Error running sort: $!\n";
print WRITE join("\n",5,2,8,7,9,1,3,6,4,0),"\n";
close(WRITE);
while (<READ>)
{
  print "$0 read $_";
}


#!/usr/bin/perl -w

# This is t6b

use strict;

use vars qw(@a);
while (<>)
{
  push(@a,$_);
}

# OK, now we've gotten EOF.
print sort @a;
[download]

Please, if you are going to post a benchmark and results, do so responsibly. The code you posted has (at least) two errors:

timethese( 100], {

Where'd that spurious ']' come from? I realize this was probably a cut-n-paste error, but still...

open PROG, ">/dev/nul";

This one is more serious. It implies that you tested printing your strings to a non-existent file handle. Ooops.

Benchmark: timing 100 iterations of join, local, manual...

Wait... what about 'html'? So, I guess you ran that later and added it into your results?

I probably would have missed all of this had I not been suspicious of your results. I would have guessed the 'html' version to be the fastest by far... so I had to check for myself. Here are the results I got, after correcting the errors noted above:

Frankly, I still don't know how you managed to get such poor figures for the 'html' code.

-sauoq
"My two cents aren't worth a dime.";