Hi. This is my first time on perlmonks - I am a co-worker of liverpole's, and he and I have been discussing his question. I hope I am not out-of-line by continuing the discussion.

(I was close-but-off when we discussed it here at work. I'd surmised it was I/O blocking of some type, but had presumed it was related to code for output that he's since eliminated. It wasn't the problem.)

I hadn't considered file closures - because to my limited understanding of UNIX file systems (liverpole is using one of the Red Hat Linux systems), file closure was relatively independent from one system process to another. A process on UNIX will close a file, any unwritten buffers will write out, any reference counts will be decremented, and the process will continue. (The kernel may take further action if reference counts reach zero, but that is outside of the process, and irrelevant to it.)

Clearly, you have demonstrated that there is a coordination of file closures, and that the main parent was blocking on closure at an inconvenient time (at the end of the local scope). It doesn't surprise me, therefore, that moving the file handle or keeping a reference count to the file handle until the program exits will postpone that blocking until it no longer matters. (Other than efficiency, who cares if the parent program blocks during exit, until the child also exits?)

But - what in the world is causing/permitting the coordination between the two processes? Is it a Perl construct to do so? What if the child, instead of simply forking, performed an exec as well - would that prevent or reduce any coordination?

I'm truly convinced that there is unexpected coordination of the files on file closure (whether that file closure is implicit or explicit). But I'm not a Frater of Perl enough to know how or why such coordination is taking place?

Help? Don't worry, liverpole will tell me if anyone replies. Thanks for reading, and tolerating. And answering.