SDL_net uses blocking writes?

From what I understand, SDL_net leaves all its sockets (except for the
accept() one) in blocking mode? Does anyone really use SDL_net in any
significant way?

Asking for a tiny bit too much in SDLNet_TCP_Recv (I’m mostly
experienced with TCP rather than UDP) will cause it to block until all
the data has arrived, sending is pretty much the same (a certain
number of calls might return quickly because it will go in the kernel
buffers, but when those fill up, it will block).

This means that it’s impossible to do communication safely without a
thread for each direction, per socket (which also cannot be used for
anything else, because they might get stuck at any time), or otherwise
you risk deadlock, if everything isn’t “just right”. Those threads
will also be hard to deal with, as they are going to spend large
chunks of time stuck in the send/recv calls, and can’t be signalled in
a cross-platform way (specifically, on Windows, it’s going to get down
to TerminateThread often, that has all sorts of nasty side-effects,
not to mention that this is quite messy overall).

That said, I’m not just idly complaining, I’d like to be able to help
make things awesome. I’m going over this as we’ve been porting Quadra
(http://code.google.com/p/quadra/) to SDL, and I’m also one of the
developers of WvStreams (http://code.google.com/p/wvstreams/, which
you most likely already have on your computer if you’re using Linux).
I’d rather develop in C++, but if it’s to help make a base library
that a lot of people end up using be awesome, I’m willing to bite the
bullet. :wink:

Of note, I’ve also managed to make small test programs that use SDL
(X11, at least, and I think I could make a version of the same for
Windows) that has a single unified event loop for both SDL events and
network events, with such interesting characteristics as being
completely single-threaded (no context switching or locking overhead),
just about zero CPU utilization when idle (say, at a menu screen with
no animation), and most importantly, no extra latency for events (no
SDL_Delay(10), that can delay an event by up to 10 ms, and this
applies to both networking and normal SDL events). It’s pretty sweet.
:-)–
http://pphaneuf.livejournal.com/

You might want to take a look at net2 at gameprogrammer.com.

Bob PendletonOn 4/23/08, Pierre Phaneuf wrote:

From what I understand, SDL_net leaves all its sockets (except for the
accept() one) in blocking mode? Does anyone really use SDL_net in any
significant way?

Asking for a tiny bit too much in SDLNet_TCP_Recv (I’m mostly
experienced with TCP rather than UDP) will cause it to block until all
the data has arrived, sending is pretty much the same (a certain
number of calls might return quickly because it will go in the kernel
buffers, but when those fill up, it will block).

This means that it’s impossible to do communication safely without a
thread for each direction, per socket (which also cannot be used for
anything else, because they might get stuck at any time), or otherwise
you risk deadlock, if everything isn’t “just right”. Those threads
will also be hard to deal with, as they are going to spend large
chunks of time stuck in the send/recv calls, and can’t be signalled in
a cross-platform way (specifically, on Windows, it’s going to get down
to TerminateThread often, that has all sorts of nasty side-effects,
not to mention that this is quite messy overall).

That said, I’m not just idly complaining, I’d like to be able to help
make things awesome. I’m going over this as we’ve been porting Quadra
(http://code.google.com/p/quadra/) to SDL, and I’m also one of the
developers of WvStreams (http://code.google.com/p/wvstreams/, which
you most likely already have on your computer if you’re using Linux).
I’d rather develop in C++, but if it’s to help make a base library
that a lot of people end up using be awesome, I’m willing to bite the
bullet. :wink:

Of note, I’ve also managed to make small test programs that use SDL
(X11, at least, and I think I could make a version of the same for
Windows) that has a single unified event loop for both SDL events and
network events, with such interesting characteristics as being
completely single-threaded (no context switching or locking overhead),
just about zero CPU utilization when idle (say, at a menu screen with
no animation), and most importantly, no extra latency for events (no
SDL_Delay(10), that can delay an event by up to 10 ms, and this
applies to both networking and normal SDL events). It’s pretty sweet.
:slight_smile:


http://pphaneuf.livejournal.com/


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

±-------------------------------------+

Pierre,

Will running the network call in a thread not solve your problem. SDL
already has a thread library.On Tue, Apr 29, 2008 at 10:01 PM, Bob Pendleton wrote:

You might want to take a look at net2 at gameprogrammer.com.

Bob Pendleton

On 4/23/08, Pierre Phaneuf wrote:

From what I understand, SDL_net leaves all its sockets (except for the
accept() one) in blocking mode? Does anyone really use SDL_net in any
significant way?

Asking for a tiny bit too much in SDLNet_TCP_Recv (I’m mostly
experienced with TCP rather than UDP) will cause it to block until all
the data has arrived, sending is pretty much the same (a certain
number of calls might return quickly because it will go in the kernel
buffers, but when those fill up, it will block).

This means that it’s impossible to do communication safely without a
thread for each direction, per socket (which also cannot be used for
anything else, because they might get stuck at any time), or otherwise
you risk deadlock, if everything isn’t “just right”. Those threads
will also be hard to deal with, as they are going to spend large
chunks of time stuck in the send/recv calls, and can’t be signalled in
a cross-platform way (specifically, on Windows, it’s going to get down
to TerminateThread often, that has all sorts of nasty side-effects,
not to mention that this is quite messy overall).

That said, I’m not just idly complaining, I’d like to be able to help
make things awesome. I’m going over this as we’ve been porting Quadra
(http://code.google.com/p/quadra/) to SDL, and I’m also one of the
developers of WvStreams (http://code.google.com/p/wvstreams/, which
you most likely already have on your computer if you’re using Linux).
I’d rather develop in C++, but if it’s to help make a base library
that a lot of people end up using be awesome, I’m willing to bite the
bullet. :wink:

Of note, I’ve also managed to make small test programs that use SDL
(X11, at least, and I think I could make a version of the same for
Windows) that has a single unified event loop for both SDL events and
network events, with such interesting characteristics as being
completely single-threaded (no context switching or locking overhead),
just about zero CPU utilization when idle (say, at a menu screen with
no animation), and most importantly, no extra latency for events (no
SDL_Delay(10), that can delay an event by up to 10 ms, and this
applies to both networking and normal SDL events). It’s pretty sweet.
:slight_smile:


http://pphaneuf.livejournal.com/


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

±-------------------------------------+


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org