close() on opened pipe fails in forked child

saintmike has asked for the wisdom of the Perl Monks concerning the following question:

If you open a pipe in a parent process via open(), then spawn a child, which then runs the close() on the open handle, close() fails with "No child processes":

open PIPE, "| cat" or die $!;

my $pid = fork();

if( $pid == 0 ) {
    # child
    close PIPE or die $!;
    exit 0;
}

sleep 1;
my $reaped = waitpid(-1, 0 );
print "pid $reaped\n";
[download]

Now you'll certainly say "Don't do that!" but the problem is that the open() happens in a module I maintain and the close() happens in its DESTROY method. If the user of the module decides that they want to spawn a child process, the error occurs! Who's to blame here? The module? The user? Perl? Should every module opening a pipe implement logic to check if the close fails for this obscure reason and suppress an error that's otherwise reported and will confuse the user?

Comment on close() on opened pipe fails in forked child Download Code

Replies are listed 'Best First'.
Re: close() on opened pipe fails in forked child by kennethk (Abbot) on May 09, 2013 at 17:04 UTC
Is there a particular reason you have to die on a close failure? I assume the close is necessary for a buffer flush. Is there a particular reason you need a global filehandle? This issue would seem to go away if you use Indirect Filehandles and let the Perl garbage collection resolve the closing. `open my $pipe, "\| cat" or die $!; my $pid = fork(); if( $pid == 0 ) { # child print $pipe "Child\n"; exit 0; } sleep 1; print $pipe "Parent\n"; my $reaped = waitpid(-1, 0 ); print "pid $reaped\n";` [download] #11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.	[reply] [d/l]
Re^2: close() on opened pipe fails in forked child by saintmike (Vicar) on May 09, 2013 at 20:04 UTC
Is there a particular reason you have to die on a close failure? I just used die() for illustration purposes, the real module handles it differently, but it must somehow handle errors on close() because they could be real errors with the command run by the pipe, and the user needs to know what's going on. Is there a particular reason you need a global filehandle? This issue would seem to go away if you use Indirect Filehandles and let the Perl garbage collection resolve the closing. The file handle is stored within the module and therefore persists until the object of the class that the module implements goes out of scope. In this case, this happens when the child terminates. I guess my issue is that this is not a "real" error, neither from the user's perspective (who just forks), or from the module owner's perspective (who just opens/closes a pipe), and therefore it shouldn't even be surfaced.	[reply]
Re^3: close() on opened pipe fails in forked child by kennethk (Abbot) on May 09, 2013 at 20:34 UTC
Well, you could come up with a hackish work around by caching the value of $$ when you open your pipe, and then check to see if the value is equivalent when you close it to decide if the error should be propagated or not, e.g. `my $status = $pipe->close; die $! if $$ != $mainpid;` [download] If you are confident that only the parent thread will access the output methods, you could write the above more like: `if ($$ == $mainpid) { $pipe->close or die $!; }` [download] Both of these solutions require you to put the effort into handling the issue, which is less aesthetically pleasing to me, but gets the job done. I cannot come up with an effective way of propagating real errors and blocking apparent errors from the fork that seems elegant. The only other possibility that occurs to me is to check if the pipe process is a child of the current process before error propagation (as opposed to caching pid), but this does not strike me as fundamentally cleaner. #11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.	[reply] [d/l] [select]


Your skill will accomplish what the force of many cannot
	PerlMonks