Bug 40852

Summary:	select(2): document action of close()'ing a fd during a select()
Product:	Documentation	Reporter:	Stephane Fillod (fillods)
Component:	man-pages	Assignee:	documentation_man-pages (documentation_man-pages)
Status:	RESOLVED CODE_FIX
Severity:	normal	CC:	mtk.manpages
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	n/a	Subsystem:
Regression:	No	Bisected commit-id:

Description Stephane Fillod 2011-08-10 13:28:24 UTC

I had a hard time figuring out what is the Linux's expected behavior of select() syscall when a file descriptor is close()'d in the meantime. The man page 3.27-1ubuntu2 lacks this piece of information. This is on Ubuntu 11.04.

Like many other OS, I would have expect select() to bail out on Linux, but it is not the case. When some other thread close() a file descriptor currently watched by select(), Linux does not make the select() syscall to return with errno=EBADF, it simply ignores it and does not return.
Please note that this behavior is undefined in POSIX. 

IMO, this has to be appropriately documented in the select(2) man page.

Maybe something like "The select() system call never returns if a file descriptor is closed in the meantime. This behavior is undefined in POSIX".[3]

Rem: this case is not to be confused with a file that has already been closed before calling select().

Background:

[1] http://stackoverflow.com/questions/543541/what-does-select2-do-if-you-close2-a-file-descriptor-in-a-separate-thread/543595#543595

[2] http://lkml.indiana.edu/hypermail/linux/kernel/0106.0/0768.html

[3] https://lists.linux-foundation.org/pipermail/bugme-new/2003-April/008335.html

Comment 1 Michael Kerrisk 2012-08-17 05:45:03 UTC

Confirmed, with the program below.

#include <sys/time.h>
#include <pthread.h>
#include <sys/types.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>

#define errExit(msg) 	do { perror(msg); exit(EXIT_FAILURE); \
			} while (0)

#define errExitEN(en, msg) \
    			do { errno = en; perror(msg); \
    			     exit(EXIT_FAILURE); } while (0)

static void *
threadFunc(void *arg)
{
    sleep(2);
    
    printf("Closing file descriptor\n");
    close(STDIN_FILENO);

    return NULL;
} /* threadFunc */

int
main(int argc, char *argv[])
{
    pthread_t t1;
    fd_set readfds;
    int ready, s;

    FD_ZERO(&readfds);
    FD_SET(STDIN_FILENO, &readfds);

    s = pthread_create(&t1, NULL, threadFunc, (void *) 1);
    if (s != 0)
	errExitEN(s, "pthread_create");

    printf("Main thread about to call select()\n");

    ready = select(STDIN_FILENO + 1, &readfds, NULL, NULL, NULL);
    if (ready == -1)
	errExit("select");

    s = pthread_join(t1, NULL);
    if (s != 0)
	errExitEN(s, "pthread_join");

    printf("Main thread exiting\n");

    exit(EXIT_SUCCESS);
}

Comment 2 Michael Kerrisk 2012-08-17 06:30:36 UTC

I added some text under NOTES in select(2).

--- a/man2/select.2
+++ b/man2/select.2
@@ -411,6 +411,22 @@ when
 .B _GNU_SOURCE
 is defined.
 Since glibc 2.2.2 the requirements are as shown in the SYNOPSIS.
+.SS Multithreaded applications
+If a file descriptor being monitored by
+.BR select ()
+is closed in another thread, the result is unspecified.
+On some UNIX systems,
+.BR 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
+.BR 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
+.BR select ().
+In summary, any application that relies on a particular behavior
+in this scenario must be considered buggy.
 .SS "Linux Notes"
 The
 .BR pselect ()

Comment 3 Michael Kerrisk 2012-08-17 06:38:16 UTC

Also added a note to poll(2) that points to the discussion in select(2).

Comment 4 Michael Kerrisk 2012-08-17 06:42:06 UTC

Also added a note to epoll_wait(2) that points to the discussion in select(2).