http://qs321.pair.com?node_id=574349

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

Though I noticed this description of $SYSTEM_FD_MAX ($^F) in perlvar:

The maximum system file descriptor, ordinarily 2. System file descriptors are passed to exec()ed processes, while higher file descriptors are not.
I could not find much more describing this behaviour in the standard Perl docs. I further experimented with two programs topen.pl and topensys.pl, as shown below:
# topen.pl use strict; use warnings; open(my $fh, '<', "zz.tmp") or die "open zz.tmp: $!"; my $fdnew = fileno($fh); print "fdnew=$fdnew\n"; # topensys.pl use strict; use warnings; use Fcntl; $|=1; # $^F = 3; # uncomment this line to inherit $fh_g my $tmpfile_g = 'tmpglob.tmp'; open(my $fh_g, '<', $tmpfile_g) or die "error: open '$tmpfile_g': $!"; if (0) { # Fiddle with close-on-exec, works on Unix, not Windows. my $val = fcntl($fh_g, F_GETFD, 0) or die "error: fcntl: $!"; # $val |= FD_CLOEXEC; # turn on $val &= ~FD_CLOEXEC; # turn off fcntl($fh_g, F_SETFD, $val) or die "error: fcntl: $!"; } my $rc = system("$^X topen.pl"); sleep(30); print "rc=$rc\n";

To run this test, first create empty tmpglob.tmp and zz.tmp files, then run topensys.pl, which forks topen.pl. The sleep is there so I could run OS file handle utilities to peek at what file handles each process had open.

This all worked as advertised on Unix, at least that's what I saw, both via the fd reported by topen.pl and confirmed by the lsof utility.

However, on Windows, it seems that the underlying OS file handle for the tmpglob.tmp file is being inherited by topen.pl; that's what sysinternals handle utility told me.

Before rushing off and perl-bugging this, I thought I better discuss it first in case I've missed something.

Since Windows does not support FD_CLOEXEC, you can't use Fcntl to work around this annoyance. Though Windows can support this behaviour (for example, via CRT O_NOINHERIT flag), I don't know of any way to get at it from pure Perl code. I was thinking a new close_on_exec() method for IO::Handle might be nice. Thoughts?

Replies are listed 'Best First'.
Re: Comparing close-on-exec behaviour between Unix and Windows
by BrowserUk (Patriarch) on Sep 22, 2006 at 13:04 UTC

    tye's Win32API::File contains all the code that is needed to implement this particular piece of the panopoly of fcntl() functionality. Namely FdGetOsFHandle() to gain access to the native filehandle, and SetHandleInformation() to set/clear the inheritability flag on that handle.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
Re: Comparing close-on-exec behaviour between Unix and Windows
by strredwolf (Chaplain) on Feb 18, 2013 at 15:07 UTC

    Related but tangental, you did give me the solution for getting a clean report out of ffmpeg. Code soon!

    Information doesn't want to be free. It wants to be feline.