有没有办法获得套接字描述符，因为哪个select（）调用返回EBADF？

Question

I have a code in which I am using select() function call to poll a list of sockets added to readfds set for any incoming data.

while(1) {
    ret = select(n,&readfds,NULL,NULL,&tv);
    if(ret == -1) {
        perror("Select Failed");
    } else if (ret == 0){
        printf("Select Timeout\n");
    } else {
           recv(clientSocket, buffer, 1024, 0);
           printf("Data received: %s",buffer);
    }
}

I have so many sockets added to readfds list. There is another thread in my code which is closing a socket in readfds list (This removal of socket from the list is not expected behavior). So if the socket is getting removed in another thread, above while loop is throwing "Select Failed : Bad file descriptor".

1) One way to avoid this is to fix the bug in other thread to stop removal of the socket from the list

2) Another way is to get the socket which is giving bad file descriptor error in select function call and remove that from the list of sockets mentioned in readfds (I can add the same socket to the list again in another part of the program).

I am trying for the first option. Mean while I also wanted to know, is there any way to get the socket descriptor due to which select() call is returning EBADF ?

Answer 1

1. Select won't support more than FD_SETSIZE number of descriptors due to size limit of fd_set data structure. Often FD_SETSIZE is 1024.
2. The way your posted code use Select is problematic. Since select modifies the passed fd_sets so none of them can be reused, you need to update fd_set and max fd number each time you prepare for Select call.
3. Select doesn't support multithreaded use very well because it's not designed so. According to man select:

Multithreaded applications

If a file descriptor being monitored by select() is closed in another thread, the result is unspecified. On some UNIX systems, select() unblocks and returns, with an indication that the file descriptor is ready (a subsequent I/O operation will likely fail with an error, unless another the file descriptor reopened between the time select() returned and the I/O operations was performed). On Linux (and some other systems), closing the file descriptor in another thread has no effect on select(). In summary, any application that relies on a partic‐ ular behavior in this scenario must be considered buggy.

4. Try using epoll which is more modern and back it with a thread pool.

A useful guide is http://www.ulduzsoft.com/2014/01/select-poll-epoll-practical-difference-for-system-architects/ .

Answer 2

If another thread is closing a filedescriptor, and you want to use the same descriptor in main thread (select()), you have in theory a "race condition". Using the same resource in more than one thread at any given time.

You should protect the filedescriptor references, just like you protect concurrent memory access. The filedescriptor number can be reused on next accept/connect/open call, causing inconsistency with your current approach.