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.