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).
See also:
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.
In reply to Re: Passing a File Descriptor to a New Process on Windows
by eyepopslikeamosquito
in thread Passing a File Descriptor to a New Process on Windows
by hardburn
For: | Use: | ||
& | & | ||
< | < | ||
> | > | ||
[ | [ | ||
] | ] |