We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

In SDL_Net (specifically SDLnetTCP.c), sock->channel is set to
O_NONBLOCK for accept() on systems that support O_NONBLOCK. However,
when we're done with accept() and just normal traffic is going across,
the socket is not reset to blocking I/O on O_NONBLOCK systems. This
seems odd, since SDLNet_TCP_Send and friends do block on Linux. There
is also Windows-only code to set the socket back to block after the
accept() call, but it appears to make no such attempt on any other OS.

For some reason, the socket still appears to block on a few non-win32 systems, such as Linux, NetBSD, and OpenBSD. On FreeBSD, however a call to SDLNet_TCP_Recv gives the error EAGAIN, suggesting that the socket is in nonblocking mode. Attempting the SDLNet_TCP_Recv call repeatedly in this instance does work, so the socket still works correctly; it's just that it is in nonblocking mode. Since the code attempts to set the socket to blocking mode again for win32 platforms, I don't think this is desired behavior. Here is a patch to set the socket back to blocking mode on systems that support O_NONBLOCK.