Re: Trapping socket error in client when server goes away

For checking the state of a socket, I prefer to the system call version of select RBITS, WBITS, EBITS, TIMEOUT. It requires a little more setup using vectors and such, but the result is finer control, IMHO. -ben (perlcapt)

# socket is already setup, and client accepted
# set up masks for use by select
my ($rin,$win,$ein) = ("","","");
my ($rout,$wout, $eout) = ($rin, $win, $ein);
vec($rin, fileno($client),1) = 1;
vec($win, fileno($client),1) = 1;
$ein = $rin | $win;

# -- code deleted --

# wait until the client is ready for writing
if(select(undef,$wout = $win,undef,$timeout)) {
   # <$client> or sysread
    }
# -- code deleted --
# or


# wait until client is ready for writing to
if(select(undef,$wout=$win,undef,$timeout)) {
   # print client or syswrite
}
[download]

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

Replies are listed 'Best First'.
Re^2: Trapping socket error in client when server goes away by thospel (Hermit) on Oct 20, 2004 at 15:23 UTC
Use of select does not solve the original problem, but just replaces it with a race condition. A socket can get closed between select returning writability and you doing the write. In that case he will run into exactly the same problem, the program will exit with a broken pipe message. It will just be more rare since you made the problem window smaller. Also, if you go select based, do not use <> (readline) and print (ok, you can if you are very careful). select only guarantees one read or write respectively (and even that one isn't absolutely guaranteed) These buffered operations can use multiple reads and writes.	[reply]
Re^3: Trapping socket error in client when server goes away by jfroebe (Parson) on Oct 20, 2004 at 18:33 UTC
So in other words, expect the read/write to fail. That way, if/when it does, the program won't die No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1	[reply]