Re: File handles with forked processes

Much to my surprise the file opened in the first child is also opened in the second child according to process explorer (although I doubt the file handle created in the first child is shared)

This is the promise of fork, even of emulated fork, clone everything, so this is what you should expect to happen.

Maybe you want to fork before opening file handles?

or not fork at all , spawn a background process Proc::Background...?

Comment on Re: File handles with forked processes

Replies are listed 'Best First'.
Re^2: File handles with forked processes by mvaline (Friar) on Oct 10, 2015 at 02:05 UTC
Specifically, the `fork` Posix system call makes an exact copy of the parent process, including all memory segments. Both the parent and the child resume execution exactly as if they had each made the fork system call. Usually, program switches execution paths based on the return value of the `fork` call in order to learn whether it is the child or the parent. You are running Windows, which doesn't have the `fork` system call, so you are using Perl's emulation of it within the Perl interpreter. To learn more about the limits of this emulation, run `perldoc perlfork` or read the perldoc page here.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: File handles with forked processes
by mvaline (Friar) on Oct 10, 2015 at 02:05 UTC

Specifically, the fork Posix system call makes an exact copy of the parent process, including all memory segments. Both the parent and the child resume execution exactly as if they had each made the fork system call. Usually, program switches execution paths based on the return value of the fork call in order to learn whether it is the child or the parent.

You are running Windows, which doesn't have the fork system call, so you are using Perl's emulation of it within the Perl interpreter. To learn more about the limits of this emulation, run perldoc perlfork or read the perldoc page here.

[reply]
[d/l]
[select]