Bug 43072 (epoll_threads) - epoll & threads
Summary: epoll & threads
Status: RESOLVED CODE_FIX
Alias: epoll_threads
Product: Documentation
Classification: Unclassified
Component: man-pages (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Michael Kerrisk
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-08 11:49 UTC by Armin Rigo
Modified: 2012-04-14 20:01 UTC (History)
1 user (show)

See Also:
Kernel Version: n/a
Tree: Mainline
Regression: No


Attachments

Description Armin Rigo 2012-04-08 11:49:58 UTC
The manpages of epoll do not mention the behavior in the presence of multiple threads.  By trying it out, I found out that the following works: if one thread does epoll_wait() on an epoll in which some fd was not registered at all, and blocks; and later another thread does epoll_ctl() to add the fd; then the fd will be reported by the original thread's epoll_wait() as soon as it meets the condition.  This behavior is something that may be very useful in some situations.  As far as I see, it cannot be achieved easily with select().  I think that it should be officially mentioned in the manpages (provided it is not an accident but works this way by design).
Comment 1 Michael Kerrisk 2012-04-14 19:56:10 UTC
Thanks for the report. You are right that it's useful and cannot be achieved with select(2) and poll(2).


I added the following to epoll_wait(2):

--- a/man2/epoll_wait.2
+++ b/man2/epoll_wait.2
@@ -183,6 +183,16 @@ Library support is provided in glibc starting with version 2.6.
 .SH CONFORMING TO
 .BR epoll_wait ()
 is Linux-specific.
+.SH NOTES
+While one thread is blocked in a call to
+.BR epoll_pwait (),
+it is possible for another thread to add a file descriptor to the waited-upon
+.B epoll
+instance.
+If the new file descriptor becomes ready,
+it will cause the
+.BR epoll_wait ()
+call to unblock.
 .SH "SEE ALSO"
 .BR epoll_create (2),
 .BR epoll_ctl (2),

Note You need to log in before you can comment on or make changes to this bug.