There is IO::FDPass, which implements the appropriate Windows system calls.

For the sake of clarity, IO::FDPass doesn't implement letting a child process inherit an open file descriptor. It implements passing an open file descriptor through a Unix-domain socket (and similar functionality on Windows).

It also doesn't work with cygwin Perl.

To pass an open file descriptor to a child process in Windows Perl you actually have to pass an open low-level Windows file handle to the child and you have to create the child with something other than fork.

The core module Win32API::File includes the required functionality for looking up the low-level handle so you can inform the child where to find it and for opening a Perl file handle so you can read from and/or write to it.

There are several ways to spawn the child process, including: Win32::Process::Create(), system(1,...) (see perlport), system("start ...").

Unfortunately, although I've done this successfully before and have helped others do it at PerlMonks, none of us has actually posted working examples of this as far as I can tell.

But it wasn't particularly hard. You do the steps the same as on Unix except:

• You set the "INHERIT" flag via Win32API::File::SetHandleInformation().
• You get the low-level handle via FdGetOsFHandle().
• You don't use fork() (see above).
• You "open" the handle via OsFHandleOpen().

- tye        

Thanks, tye, have this all figured out now.

fd_pass.pl

#!/usr/bin/perl
use v5.14;
use warnings;
use Win32API::File 'FdGetOsFHandle';


my $FILE = shift or die "Need file to read\n";


say "Opening file";
open( my $in, '<', $FILE ) or die "Can't open '$FILE': $!\n";

# Get the real FD from Windows
my $fd = FdGetOsFHandle( fileno($in) );

say "Spawning child process";
my $pid = system(1, 'perl', './fd_get.pl', $fd )
    or die "Could not spawn child process: $!\n";

wait;
[download]

fd_get.pl

#!/usr/bin/perl
use v5.14;
use warnings;
use Win32API::File 'OsFHandleOpen';

my $FD = shift or die "Need file descriptor\n";
OsFHandleOpen( *IN, $FD, 'r' )
    or die "Could not open file descriptor '$FD': $!\n";


while(<IN>) {
    chomp;
    say "Got in child: $_";
}

close IN;
[download]

---

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

I remember writing a test t/run/cloexec.t a few years back. The comment block from this test may be of interest:

# Test inheriting file descriptors across exec (close-on-exec).
#
# perlvar describes $^F aka $SYSTEM_FD_MAX as follows:
#
#  The maximum system file descriptor, ordinarily 2.  System file
#  descriptors are passed to exec()ed processes, while higher file
#  descriptors are not.  Also, during an open(), system file descripto
+rs
#  are preserved even if the open() fails.  (Ordinary file descriptors
#  are closed before the open() is attempted.)  The close-on-exec
#  status of a file descriptor will be decided according to the value 
+of
#  C<$^F> when the corresponding file, pipe, or socket was opened, not
#  the time of the exec().
#
# This documented close-on-exec behaviour is typically implemented in
# various places (e.g. pp_sys.c) with code something like:
#
#  #if defined(HAS_FCNTL) && defined(F_SETFD)
#      fcntl(fd, F_SETFD, fd > PL_maxsysfd);  /* ensure close-on-exec 
+*/
#  #endif
#
# This behaviour, therefore, is only currently implemented for platfor
+ms
# where:
#
#  a) HAS_FCNTL and F_SETFD are both defined
#  b) Integer fds are native OS handles
#
# ... which is typically just the Unix-like platforms.
#
# Notice that though integer fds are supported by the C runtime librar
+y
# on Windows, they are not native OS handles, and so are not inherited
# across an exec (though native Windows file handles are).
[download]

See also:

• Comparing close-on-exec behaviour between Unix and Windows
• close_on_exec in Perl : close socket opened in parent process when fork child , is not working

I'm afraid it's too long ago, and I don't remember why I was so interested close-on-exec back then, but as tye points out above, it is possible to pass native Windows file handles.