In SDLnetTCP.c at line: 884 the send() call.
/* Keep sending data until it’s sent or an error occurs */
left = len;
sent = 0;
errno = 0;
do {
// len = send(sock->channel, (const char *) data, left, 0);
len = send(sock->channel, (const char *) data, left, MSG_NOSIGNAL); //RCP
if ( len > 0 ) {
sent += len;
left -= len;
data += len;
}
} while ( (left > 0) && ((len > 0) || (errno == EINTR)) );
I’ve add the MSG_NOSIGNAL flag. Without it you get nasty SIGPIPEs that
cause SDL to print out “broken pipe” and die without giving the
application a chance to deal with the error.
I’ve been doing some stress testing of SDLNet and ran into this problem.
Once in a while an error occurs and you lose a socket and then the
whole application drops over dead.
At this point I can say I’ve done a LOT of testing of SDL and this is
the only real bug I’ve found. The code I’m using to do this testing
implements an event based lawyer on top of SDLNet. It gives you an event
when data is available or a connection is made or lost. That sort of
thing. I built it so it can be compiled to do IO in either the main
thread, via polling, or it can run in a separate thread. I’ve found that
under one set of extreme conditions the threaded version uses about 66%
of the CPU time of the non-threaded version. But, in another set of
extreme conditions the threaded version can take 2 to 3 times as much
CPU times as the non-threaded version. So far I’ve test with up to 400
active threads with 401 processes each with 4 threads all running in one
box. After I get some sleep I’ll start testing across my LAN. Does
anyone have a multiprocess box they would be willing to test this on?
Bob Pendleton
You could also stick in
signal(SIGPIPE, SIG_IGN);
Somewhere at the start of you code… Preferable perhaps, since you
may want to catch that signal and do something appropriately…
Personally, I’ve always just ignored it and caught the problem from
read/recv.
While you are testing network libraries, you are welcome to try mine out
if you are bored. 
Lund
Bob Pendleton wrote:> In SDLnetTCP.c at line: 884 the send() call.
/* Keep sending data until it's sent or an error occurs */
left = len;
sent = 0;
errno = 0;
do {
// len = send(sock->channel, (const char *) data,
left, 0);
len = send(sock->channel, (const char *) data, left,
MSG_NOSIGNAL); //RCP
if ( len > 0 ) {
sent += len;
left -= len;
data += len;
}
} while ( (left > 0) && ((len > 0) || (errno == EINTR)) );
I’ve add the MSG_NOSIGNAL flag. Without it you get nasty SIGPIPEs that
cause SDL to print out “broken pipe” and die without giving the
application a chance to deal with the error.
I’ve been doing some stress testing of SDLNet and ran into this problem.
Once in a while an error occurs and you lose a socket and then the
whole application drops over dead.
At this point I can say I’ve done a LOT of testing of SDL and this is
the only real bug I’ve found. The code I’m using to do this testing
implements an event based lawyer on top of SDLNet. It gives you an event
when data is available or a connection is made or lost. That sort of
thing. I built it so it can be compiled to do IO in either the main
thread, via polling, or it can run in a separate thread. I’ve found that
under one set of extreme conditions the threaded version uses about 66%
of the CPU time of the non-threaded version. But, in another set of
extreme conditions the threaded version can take 2 to 3 times as much
CPU times as the non-threaded version. So far I’ve test with up to 400
active threads with 401 processes each with 4 threads all running in one
box. After I get some sleep I’ll start testing across my LAN. Does
anyone have a multiprocess box they would be willing to test this on?
Bob Pendleton
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
Jorgen “Lord” Lundman <@Jorgen_Lundman>
Technology Manager, Unix Administrator
Phone: +44 (0)20-86591860 Mobile: +44 (0)79-58642918
Pager: 07958642918 at one2one.net
"Rare is the person who can weigh the faults of others
without putting his thumb on the scales": Byron J. Langenfeld
Yes, I could, and I will do that. But, the documentation says that send
returns a value != to len on errors. And, that is it should do. It
should let you handle the error in your app and it should do what it is
documented to do. SIGPIPE is a blunt weapon in a situation that requires
a rapier.
Bob Pendleton
P.S.
If you library is released under LGPL and accepted as a standard part of
SDL I might test it.
Jorgen Lundman wrote:>
You could also stick in
signal(SIGPIPE, SIG_IGN);
Somewhere at the start of you code… Preferable perhaps, since you
may want to catch that signal and do something appropriately…
Personally, I’ve always just ignored it and caught the problem from
read/recv.
While you are testing network libraries, you are welcome to try mine out
if you are bored.
Lund
Bob Pendleton wrote:
In SDLnetTCP.c at line: 884 the send() call.
/* Keep sending data until it's sent or an error occurs */
left = len;
sent = 0;
errno = 0;
do {
// len = send(sock->channel, (const char *) data,
left, 0);
len = send(sock->channel, (const char *) data, left,
MSG_NOSIGNAL); //RCP
if ( len > 0 ) {
sent += len;
left -= len;
data += len;
}
} while ( (left > 0) && ((len > 0) || (errno == EINTR)) );
I’ve add the MSG_NOSIGNAL flag. Without it you get nasty SIGPIPEs that
cause SDL to print out “broken pipe” and die without giving the
application a chance to deal with the error.
I’ve been doing some stress testing of SDLNet and ran into this
problem. Once in a while an error occurs and you lose a socket and
then the whole application drops over dead.
At this point I can say I’ve done a LOT of testing of SDL and this is
the only real bug I’ve found. The code I’m using to do this testing
implements an event based lawyer on top of SDLNet. It gives you an
event when data is available or a connection is made or lost. That
sort of thing. I built it so it can be compiled to do IO in either the
main thread, via polling, or it can run in a separate thread. I’ve
found that under one set of extreme conditions the threaded version
uses about 66% of the CPU time of the non-threaded version. But, in
another set of extreme conditions the threaded version can take 2 to 3
times as much CPU times as the non-threaded version. So far I’ve test
with up to 400 active threads with 401 processes each with 4 threads
all running in one box. After I get some sleep I’ll start testing
across my LAN. Does anyone have a multiprocess box they would be
willing to test this on?
Bob Pendleton
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-----------------------------------------+
- Bob Pendleton, an experienced C/C++/Java +
- UNIX/Linux programmer, researcher, and +
- system architect, is seeking full time, +
- consulting, or contract employment. +
- Resume: http://www.jump.net/~bobp +
- Email: @Bob_Pendleton +
±-----------------------------------------+