http://www.perlmonks.org?node_id=535209


in reply to (Seemingly) Broken interactions between Net::Server and IO::Pipe?

I couldn't find it actually documented that Net::Server redirects STDIN and STDOUT as you appear to expect it to. It is implied by the documentation but I saw no actual mention of this fact, though it was rather a quick scan of the documentation. I was expecting to find something quite explicit on that point.

Rummaging through the code I find:

*STDIN = \*{ $prop->{client} }; *STDOUT = \*{ $prop->{client} } if ! $prop->{client}->isa('IO::Soc +ket::SSL'); # ... select(STDOUT);

Which is a pretty lousy way to do something like this. Copying file handles via symbol table glob manipulations is a pretty fundamentally broken technique in my experience. I've found it to be buggy. More importantly, it violates important properties of file handles and file descriptors.

If you want to "duplicate some handles" (as a comment in the code notes), then you should dup() them, which is done as documented in open: open STDIN, "<&" . fileno($prop->{client}) ..., for example; or use "<&=" if you just want to fdopen() rather than dup().

Of course, that would interfere with "magical" file handles (such a tied ones), so the code should probably look more like:

my $fileno= fileno $prop->{client}; if( defined $fileno ) { open STDIN, "<&$fileno" or die ...; open STDOUT, ">&$fileno" or die ...; } else { close STDIN; close STDOUT; *STDIN= \*{ $prop->{client} }; *STDOUT= \*{ $prop->{client} }; }

Note that I close STDIN and STDOUT before I overwrite them, as my experience is that the relation between glob life cycle and file handle life cycle is buggy.

Unfortunately, none of this looks to me like a "smoking gun" to explain your particular problem. But you could try patching Net/Server.pm and see if it makes a difference.

If I were having this problem, then I'd debug the server and watch what sockets gets created when a connection is opened and what STDOUT gets set to before my method gets called.

I suspect that you could even stop using IO::Pipe and you'd still have this problem.

- tye