• Uncategorized

About c : Unblock-recvfrom-when-socket-is-closed

Question Detail

Let’s say I start a thread to receive on a port. The socket call will block on recvfrom.
Then, somehow in another thread, I close the socket.

On Windows, this will unblock recvfrom and my thread execution will terminate.

On Linux, this does not unblock recvfrom, and as a result, my thread is sitting doing nothing forever, and the thread execution does not terminate.

Can anyone help me with what’s happening on Linux? When the socket is closed, I want recvfrom to unblock

I keep reading about using select(), but I don’t know how to use it for my specific case.

Question Answer

Call shutdown(sock, SHUT_RDWR) on the socket, then wait for the thread to exit. (i.e. pthread_join).

You would think that close() would unblock the recvfrom(), but it doesn’t on linux.

Here’s a sketch of a simple way to use select() to deal with this problem:

// Note: untested code, may contain typos or bugs
static volatile bool _threadGoAway = false;

void MyThread(void *)
   int fd = (your socket fd);
      struct timeval timeout = {1, 0};  // make select() return once per second

      fd_set readSet;
      FD_SET(fd, &readSet);

      if (select(fd+1, &readSet, NULL, NULL, &timeout) >= 0)
         if (_threadGoAway)
            printf("MyThread:  main thread wants me to scram, bye bye!\n");
         else if (FD_ISSET(fd, &readSet))
            char buf[1024];
            int numBytes = recvfrom(fd, buf, sizeof(buf), 0);
            [...handle the received bytes here...]
      else perror("select");

// To be called by the main thread at shutdown time
void MakeTheReadThreadGoAway()
   _threadGoAway = true;
   (void) pthread_join(_thread, NULL);   // may block for up to one second

A more elegant method would be to avoid using the timeout feature of select, and instead create a socket pair (using socketpair()) and have the main thread send a byte on its end of the socket pair when it wants the I/O thread to go away, and have the I/O thread exit when it receives a byte on its socket at the other end of the socketpair. I’ll leave that as an exercise for the reader though. 🙂

It’s also often a good idea to set the socket to non-blocking mode also, to avoid the (small but non-zero) chance that the recvfrom() call might block even after select() indicated the socket is ready-to-read, as described here. But blocking mode might be “good enough” for your purpose.

Not an answer, but the Linux close man page contains the interesting quote:

It is probably unwise to close file descriptors while they may be in
use by system calls in other threads in the same process. Since a file
descriptor may be reused, there are some obscure race conditions that
may cause unintended side effects.

You are asking for the impossible. There is simply no possible way for the thread that calls close to know that the other thread is blocked in recvfrom. Try to write code that guarantees that this happens, you will find that it is impossible.

No matter what you do, it will always be possible for the call to close to race with the call to recvfrom. The call to close changes what the socket descriptor refers to, so it can change the semantic meaning of the call to recvfrom.

There is no way for the thread that enters recvfrom to somehow signal to the thread that calls close that it is blocked (as opposed to being about to block or just entering the system call). So there is literally no possible way to ensure the behavior of close and recvfrom are predictable.

Consider the following:

  1. A thread is about to call recvfrom, but it gets pre-empted by other things the system needs to do.
  2. Later, the thread calls close.
  3. A thread started by the system’s I/O library calls socket and gets the same decsriptor as the one you closed.
  4. Finally, the thread calls recvfrom, and now it’s receiving from the socket the library opened.


Don’d ever do anything even remotely like this. A resource must not be released while another thread is, or might be, using it. Period.

You may also like...

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.