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