@AHodsdon wrote:
Further searching on the net turned up:
http://tangentsoft.net/wskfaq/newbie.html#wouldblock:
2.8 – Winsock keeps returning the error WSAEWOULDBLOCK. What’s wrong with my program?
Not a thing. WSAEWOULDBLOCK is a perfectly normal occurrence in programs using non-blocking and asynchronous sockets. It’s Winsock’s way of telling your program “I can’t do that right now, because I would have to block to do so.”The next question is, how do you know when it’s safe to try again? In the case of asynchronous sockets, Winsock will send you an FD_WRITE message after a failed send() call when it is safe to write; it will send you an FD_READ message after a recv() call when more data arrives on that socket. Similarly, in a non-blocking sockets program that uses select(), the writefds will be set when it’s okay to write, and the readfds will be set if there is data to read.
Note that Win9x has a bug where select() can fail to block on a nonblocking socket. It will signal one of the sockets, which will cause your program to call recv() or send() or similar. That function will return WSAEWOULDBLOCK, which can be quite a surprise. So, a program using select() under Win9x has to be able to deal with this error at any time.
This gets to a larger issue: whenever you use some form of nonblocking sockets, you have to be prepared for WSAEWOULDBLOCK at any time. It’s simply a matter of defensive programming, just like checking for null pointers.
Can firefly just wait for a FD_WRITE message?
Yeah, but when you do, it kicks the socket back into nonblocking mode. Or something does. I’m not sure why the socket keeps going nonblocking. It think it might be the WSAAsyncSelect. I might just have to rip all that crap out and just use the bsd select. Sucks, because then I can’t select on sockets and files (using WaitForMultipleObjects), but so it goes, I guess.
Windows.
— Ron