- Forum
- General C++ Programming
- Recv blocking after select
Recv blocking after select
Hi.
What I'm fighting with is a recv call. This recv call is firmly conditioned by a FD_ISSET() call, along with its select. So basically after select() is run, FD_ISSET happily and innocently returns true, but just one line below, my recv call gets stuck into the marshes (until of course the next message bumps into the awaited socket). While having trouble with this blocking call, I noticed the following thread:
http://stackoverflow.com/questions/4563577/is-it-necessary-to-reset-the-fd-set-between-select-system-call
What's it saying is that the fd_set indeed is necessary to be reset between two select calls. What I'm not sure if is what does "resetting a fd_set" actually mean? Does it mean calling FD_ZERO and re-adding all the sockets into the descriptor by using FD_SET? That would sound rather strange, because it that would be the case, then what's the point of FD_CLR?
Thanks.
Other than that, any idea why would a recv call suddenly decide to block out of nowhere?
[Edit] Corrected the wrong macro names
[Edit] Nope, seems like after doing the FD_ZERO trick and reloading everything recv is still equally stubborn. For the moment I keep using my old method of copying the already set file descriptor and using the copy for FD_ISSET actions. It works perfectly in other situations. Not sure what makes the difference in this case.
What I'm fighting with is a recv call. This recv call is firmly conditioned by a FD_ISSET() call, along with its select. So basically after select() is run, FD_ISSET happily and innocently returns true, but just one line below, my recv call gets stuck into the marshes (until of course the next message bumps into the awaited socket). While having trouble with this blocking call, I noticed the following thread:
http://stackoverflow.com/questions/4563577/is-it-necessary-to-reset-the-fd-set-between-select-system-call
What's it saying is that the fd_set indeed is necessary to be reset between two select calls. What I'm not sure if is what does "resetting a fd_set" actually mean? Does it mean calling FD_ZERO and re-adding all the sockets into the descriptor by using FD_SET? That would sound rather strange, because it that would be the case, then what's the point of FD_CLR?
Thanks.
Other than that, any idea why would a recv call suddenly decide to block out of nowhere?
[Edit] Corrected the wrong macro names
[Edit] Nope, seems like after doing the FD_ZERO trick and reloading everything recv is still equally stubborn. For the moment I keep using my old method of copying the already set file descriptor and using the copy for FD_ISSET actions. It works perfectly in other situations. Not sure what makes the difference in this case.
Last edited on
By searching and researching on the internet, I found a suggestion saying that it might be necessary to set the sockets as non-blocking, even when using a select call. However, I get "fcntl is not declared in this scope" errors even if included <fnctl.h>. It's not a library linking problem, because that would throw undefined references.
Still no idea what is going on.
By the way, running CodeBlocks with its GCC on Win7.
Still no idea what is going on.
By the way, running CodeBlocks with its GCC on Win7.
You can use select()/recv() with blocking sockets. Your problem is that haven't an agreed protocol between the sender and receiver, and as a result the reciever trying to read more than was actually sent.
If you move to non-blobking sockets, the problem won't go away. You'll end up getting unexpected asynchronous recelves that you'll have to deal with.
It's better to just fix the protocol.
If you move to non-blobking sockets, the problem won't go away. You'll end up getting unexpected asynchronous recelves that you'll have to deal with.
It's better to just fix the protocol.
Topic archived. No new replies allowed.