Re: Filehandle reference lost between parent and child

This technique may be suitable for your needs.

Parent:

Waits (up to a specified timeout period) for the child to create a (uniquely) named pipe.
Writes an unordered list of records to the named pipe.
Waits for the child to exit.
Deletes the named pipe.

Child:

Opens an anonymous pipe to sort.
Creates a (uniquely) named pipe.
Reads all records from the named pipe and writes them to the anonymous (sort) pipe.

#!/usr/bin/env perl

use strict;
use warnings;
use autodie;

use POSIX qw{mkfifo};
use Time::HiRes qw{usleep};

my $named_pipe = "pm_1085515_$$.fifo";
unlink $named_pipe if -e $named_pipe;

if (fork) {
    my $timeout = 2;
    local $SIG{ALRM} = sub { die "Timed out after $timeout seconds" };
    alarm $timeout;
    usleep 1e3 until -p $named_pipe;
    alarm 0;

    open my $writer, '>', $named_pipe;
    print $writer "$_\n" for qw{B D C A};
    close $writer;
    wait;
    unlink $named_pipe;
}
else {
    open my $sorter, '|-', 'sort';
    mkfifo $named_pipe, 0600;
    open my $reader, '<', $named_pipe;
    print $sorter $_ while <$reader>;
    close $reader;
    close $sorter;
}
[download]

Input:

B
D
C
A
[download]

Output:

A
B
C
D
[download]

-- Ken

Comment on Re: Filehandle reference lost between parent and child Select or Download Code

Replies are listed 'Best First'.
Re^2: Filehandle reference lost between parent and child by italdesign (Novice) on May 09, 2014 at 18:30 UTC
Named pipe works! MANY thanks Ken. I googled but didn't see an answer to this: if you don't delete the named pipe after all is done, will it contain all the data that was passed to it? I tried to find out by running more, less, and cat on the named pipe, but they don't seem to work (probably by design). Also, is there a way to find out the actual size of the named pipe? (I guess it always reports 0).	[reply]
Re^3: Filehandle reference lost between parent and child by kcott (Archbishop) on May 09, 2014 at 23:57 UTC
In my script, deletion of the named pipe occurred in two places: `unlink $named_pipe if -e $named_pipe;` This was partly to start with a clean slate and also a bit of defensive programming. Note that it only checks for filename existence (-e); not specifically for a named pipe (which would have been -p). I'd recommend you implement a file naming convention for your named pipes that both identifes them as named pipes and also identifies their source (in my script that was: `pm` for this site, your OP's node ID, parent PID and `.fifo` extension). Depending on the level of robustness required and in-house standards/policies/etc., you may want to do more than just leaving error handling to autodie (e.g. custom messages, timestamps, logging, and so on). `unlink $named_pipe;` This is just for housekeeping purposes. Without this, you could accumulate as many old named pipes as there are potential PIDs of the parent (that's tens of thousands on my system). The named pipe doesn't actually hold the data (at least, not in any implementation that I'm aware of). The data is written to, and read from, a buffer. You can close the `$writer` filehandle, open another one, and write more data to the buffer. Similarly, you can close the `$reader` filehandle, open another one, and read more data from the buffer. If you close both the `$reader` and `$writer`, the data in the buffer is lost (this has nothing to do with whether the named pipe was deleted); if the named pipe wasn't deleted, and (after closing both the `$reader` and `$writer`) you opened a new filehandle, it would start with an empty buffer. [You can have multiple readers and writers accessing the same named buffer at the same time. Multiple writers may be useful (cf. parent and child processes both writing to STDOUT at the same time); multiple readers is probably a very poor choice (again, cf. parent and child processes both trying to read from STDIN at the same time). If you do have multiple filehandles, all need to be closed for the "data in the buffer is lost" scenario (in the last paragraph) to occur.] Yes, the size of named pipes is reported as zero, e.g. `prw------- 1 ken staff 0 10 May 09:45 pm_1085515_64171.fifo` [download] Finally, do note that the script I provided was only intended to show a "technique". There may well be lots of things you'll want to tweak or substantially modifiy. -- Ken	[reply] [d/l] [select]
Re^3: Filehandle reference lost between parent and child (buffer) by tye (Sage) on May 09, 2014 at 21:38 UTC
Pipe implementations tend to have some fixed buffer size. If you fill the buffer when writing to it, then your write request will hang until somebody reads enough from the pipe to leave enough space. This tends to not be different between named pipes and unnamed pipes. - tye	[reply]