|The stupid question is the question not asked|
Comparing close-on-exec behaviour between Unix and Windowsby eyepopslikeamosquito (Canon)
|on Sep 22, 2006 at 09:55 UTC||Need Help??|
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:
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?