The parent blocks because $psyscmd goes out of scope upon the return in the parent process, and perl tries to destroy the filehandle (because the only living reference to it is from the structure referenced by $psyscmd) but finds its close() blocking on the child.
In the global case, the parent does not try to close() the file so it doesn't show up, but in the lexical case it does, because perl wants all open files to close as soon as they go out of scope (in case you rely on the behavior and try to open them again).
The file is (after fork()) held open by two processes, and perl doesn't want to lie to you about the success of close(), nor fail just because someone else is looking at the file, so (apparently) it blocks.
If you return a reference to $psyscmd it shouldn't block, because $psyscmd doesn't then have to be destroyed, and you can sync up at a later point (like when leaving the program).
I don't know that you can open a pipe handle with shared semantics, but that might be another way to close your handle without blocking, if in fact you can and perl is smart enough to know that you did (I'm sure perl is smart, it's whether you can share your end of the pipe).
Or maybe I'm just dead wrong and wasting valuable electrons... I'll be interested to see what others think.
You should be able to test my hypothesis by issuing an intentional close() on the filehandle in the parent before you return (and putting in another print). If it blocks there, then I'm at least a little bit right.
In reply to Re: Why is a deeply-bound lexical in a forked closure blocking the parent process?
by Anonymous Monk
in thread Why is a deeply-bound lexical in a forked closure blocking the parent process?
by liverpole
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |