See SetHandleInformation() and HANDLE_FLAG_INHERIT
That won't work as it only affects the inheritance of handles across CreateProcess() calls; not the CreateThread() calls that underly fork on Windows.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
Yeah, it wasn't clear to me whether the original poster was being sloppy with terms like "child process" or with the term "fork".
This makes me wonder if emulated fork on Windows (native) Perl obeys $^F when duplicating interpreter instances for new threads. Seems like it doesn't, which is weird (to me). Update: Oh, right, $^F applies to exec, not to fork().
Sentences like "The files are temporary and I need to be able to delete them without another child locking them" make me think of using Win32API::File's createFile() to open the file w/o preventing the deleting (or renaming) of the file. You would likely follow that with OsFHandleOpen() which would cause Perl do duplicate the resulting Perl file handle when creating threads. My guess is that Perl's emulated fork() uses fdopen() to duplicate file handles and I suspect that such would not impose locking against delete/rename if such is missing from the original handle. But I've never checked either of those points.
Not that I'm claiming that such is the best solution, just adding information (and even more questions).
| [reply] |