You're right that, in this particular case, STDIN is closed as a consequence of the child having terminated. OTOH, you get exactly the same behaviour, if the child is still alive, but doesn't take input (as when explicitly having closed STDIN)1. And the reason why the message can't be written wasn't what I was primarily interested in.
I was mainly just wondering why the can_write() method does essentially say "Yes, I can write", if it can't... I.e. why it can't figure out that there is some problem on the other end (or, at least, doesn't tell you). Somehow, I'd think that it would require more detailed status info to tell that the process on the other end is actually listening and ready to receive another chunk of data, than it would require to simply detect that all communication has been shut down...
However, I'm confident that - if that's just how things are - I'll be able to accept the fact and live with it, even if it strikes me as a little inconsequent ;)
Anyhow, thanks for taking the time to reply.
___
1 To verify, I used a little script in place of /bin/echo :
#!/usr/bin/perl my $s = shift; close STDIN; print $s x 1000000; # write enough to fill up output buffer # sleep 10; # or, just sleep
In reply to Re^4: Pipes and IO::Select's method can_write()
by almut
in thread Pipes and IO::Select's method can_write()
by almut
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |