Front page | perl.perl5.porters |
Postings from April 2019
# New Ticket Created by felipe@cpanel.net # Please include the string: [perl #134042] # in the subject line of all future correspondence about this issue. # <URL: https://rt.perl.org/Ticket/Display.html?id=134042 > Hello, Todd Rinaldo and I were talking today about this: ----- perl -MPOSIX= -e' open my $r3, "<&", \*STDIN; # opens fd 3 open my $r4, "<&", \*STDIN; # opens fd 4 print "r4 is " . fileno($r4) . "\n"; close $r3; # closes fd 3 & Perl $r3 POSIX::close(fileno($r4)); # closes fd 4, NOT Perl $r4 my($in, $out); pipe($in, $out); # opens fds 3 & 4 print "out is " . fileno($out) . "\n"; close $out; # XXX: a no-op, because Perl still has $r4 open? sysread( $in, my $buf, 512 ); # hangs ' ----- We’re wondering if the above constitutes something that would reasonably be considered a bug in Perl, and/or something that could be accommodated anyway. I’m guessing that the fact that close() is a no-op (i.e., it doesn’t close any FDs) is because PerlIO never knew about the POSIX::close() call against FD 4 and so it tracks both $r4 and $out as referring to FD 4; thus, it won’t do anything when $out is close()d because it still has another filehandle that refers to that FD. When pipe() gives FD 4, shouldn’t PerlIO set that reference counter to 1? Or should it maybe warn() that there’s a file descriptor conflict? Thank you! -Felipe GasperThread Previous