update: This might apply to the cases in the original post, but not to those in Re^2: Variable triggers global destruction hang - my mistake.
Given that your build of perl is waiting for the sub-process to finish, as indicated by the strace output you posted, my guess is that the order of cleanup is variable. If the file handles are closed before waiting for the sub-process to finish, then the sub-process exits when it reads EOF from its standard input, and then perl exits. But if perl waits for the sub-process to finish before closing file handles then it waits forever because the sub-process never reads EOF from its standard input.
Run your program under strace, wait for it to hang, then kill the cat process and see what follows. I expect you will see that after the wait completes (it will complete when cat is killed) perl will go on to close its file handles.
Explicitly close your file handles and see what happens. I don't know why it is waiting in the first place, but if it waits as part of the close I would close STDOUT first on the assumption that the magic that causes the wait is associated with FH. If you close FH first and it waits, then it should wait forever because STDOUT is still open so cat shouldn't read EOF.
In reply to Re^3: Variable triggers global destruction hang
by ig
in thread Variable triggers global destruction hang
by saintmike
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |