select.2: Note behavior if monitored file descriptor is closed in another thread

Executive summary: a sane application can't rely on any
particular behavior if another thread closes a file descriptor
being monitored by select().

See https://bugzilla.kernel.org/show_bug.cgi?id=40852

Reported-by: Stephane Fillod <fillods@users.sf.net>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2012-08-17 08:27:58 +02:00
parent 8c1d94ae86
commit 10ed041e56
1 changed files with 17 additions and 1 deletions

View File

@ -35,7 +35,7 @@
.\" 2005-03-11, mtk, modified pselect() text (it is now a system
.\" call in 2.6.16.
.\"
.TH SELECT 2 2012-05-02 "Linux" "Linux Programmer's Manual"
.TH SELECT 2 2012-08-17 "Linux" "Linux Programmer's Manual"
.SH NAME
select, pselect, FD_CLR, FD_ISSET, FD_SET, FD_ZERO \-
synchronous I/O multiplexing
@ -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 ()