[ Date Index ][
Thread Index ]
[ <= Previous by date /
thread ]
[ Next by date /
thread => ]
On Mon, Jul 08, 2002 at 03:26:59PM +0100, Theo Zourzouvillys wrote:
Surely the server blocks until the client's buffer is not full.it should be, but...
Have you tested that it's not? (my tests attached).
according so POSIX: This signal is generatred when a process writes to a socket when the other end has terminated. intereestying, as i never write to the socket on the client end.
You get the same problems with reads from bad closed sockets. I bet perl <> takes that away and the problem show up if you use sysread.
There should probablt be a different signal for a transport endpoint hangup on a socket, but what can we do about it now ;)
Not if you want to read through your buffer first, there shouldn't.
after i have read all the data, i'm callign sock->close(). i'm betting that that is causing the SIGPIPE.
Only if there server then writes. But then that would give the server a sigpipe, not the client.
So, what's getting the sigpipe, the client or the server?client is.
The client! What!? I've not done this for a while, but I'm not entirely sure when. print $! in your SIGPIPE handler for me, I'm gaggin to know what's wrong. Steve
Attachment:
client.pl
Description: Perl program
Attachment:
server.pl
Description: Perl program