Re^2: Trapping socket error in client when server goes away

There is indeed no need of an eval, Unfortunately selecting for writability (or readability for EOF) doesn't solve the real problem, which is SIGPIPE as result of writing to a closed socket. And that close can happen after the select told the socket was writable but before you got to doing the write. The conventional solution in socket programming is to simply ignore SIGPIPE (usually even globally) and use the returncodes of the I/O operations instead.

$SIG{PIPE} = "IGNORE";
....
print($socket $string) || die "Error writing to socket: $!"
[download]

(or do something else than die of course, or catch the die in some enclosing eval)

Comment on Re^2: Trapping socket error in client when server goes away Download Code

Replies are listed 'Best First'.
Re^3: Trapping socket error in client when server goes away by Anonymous Monk on Oct 20, 2004 at 03:24 UTC
Thx thospel, that seems to do the trick. BTW, as this is all on the same machine ie client+server, would UNIX socket be faster than local INET? Just wondered whether the fact there's a disk file for UNIX socket slows it down? The proj handles packets from a busy RADIUS server, so speed is of the essence...	[reply]
Re^4: Trapping socket error in client when server goes away by thospel (Hermit) on Oct 20, 2004 at 03:45 UTC
Yes, UNIX sockets will be faster. No, the disk access won't slow it down. The filesystem basically just provides a namespace for the sockets, so it's at most an initial inode lookup at. And you can get rid of even that potential disk access by putting the socket in a memory based filesystem. Systems like linux even provide abstract unix domain sockets that are anonymous (well they exist in a backing virtual filesystem), and these are nowadays supported in perl. This kind of disk access isn't something to worry about anyways on busy servers. Due to it being busy, the information will normally be cached in memory, so no actual disk access takes place (well, sometimes for atime updating, but that can be turned off and is usually write-behind anyways). But if you wanted extreme speed, you probably shouldn't have chosen perl in the first place. The processing you'll do will normally swamp this kind of detail. First write a clear well working program, and only when it turns out to be too slow, profile and start optimizing only the slow parts. Don't start guessing too early and destroy the cleanness of your program. (to give an order of magnitude, on a somewhat modern processor you should be able to handle a few 1000 protocol roundtrips per second in perl)	[reply]