YH a écrit :
> If your application is crashing in select() with a SIGBUS/SIGSEGV error
> then somehow gave bad fd_set pointers to select(). This is not related
> to clients closing/aborting their connections.
Spot on! This is exact the issue I've been troubled. If my server
program can detect the termination of a client program, it can close the
client's fd and remove it from fd_set. The problem is, my server program
could not catch SIGBUS/SIGSEGV, nor SIGPIPE or other signals from the
termination of the client program in my RH 9.0. I am not sure if it is
the RH 9.0 problem or the normal networking behavior.
Since my server program only passes a notification to high level
applications when get a packet from select(), it is not even practical
for my server program to check the return value from the read().
You MUST then change your program so that a 0 return from a read() IS taken
into account. Period.
Hint : Between the select() and the read(), a network event (or another thread
in your program) could have change the socket state.
Dont even try to argue with 'high level' if you dont follow this very basic rule.
Eric
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
