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).
- tye
In reply to Re^3: File handles with forked processes ("child")
by tye
in thread File handles with forked processes
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |