summaryrefslogtreecommitdiff
path: root/ev.pod
diff options
context:
space:
mode:
Diffstat (limited to 'ev.pod')
-rw-r--r--ev.pod13
1 files changed, 8 insertions, 5 deletions
diff --git a/ev.pod b/ev.pod
index 2f8e4d4..24d9a4e 100644
--- a/ev.pod
+++ b/ev.pod
@@ -466,11 +466,12 @@ The epoll mechanism deserves honorable mention as the most misdesigned
of the more advanced event mechanisms: mere annoyances include silently
dropping file descriptors, requiring a system call per change per file
descriptor (and unnecessary guessing of parameters), problems with dup,
-returning before the timeout value requiring additional iterations and so
-on. The biggest issue is fork races, however - if a program forks then
-I<both> parent and child process have to recreate the epoll set, which can
-take considerable time (one syscall per file descriptor) and is of course
-hard to detect.
+returning before the timeout value, resulting in additional iterations
+(and only giving 5ms accuracy while select on the same platform gives
+0.1ms) and so on. The biggest issue is fork races, however - if a program
+forks then I<both> parent and child process have to recreate the epoll
+set, which can take considerable time (one syscall per file descriptor)
+and is of course hard to detect.
Epoll is also notoriously buggy - embedding epoll fds I<should> work, but
of course I<doesn't>, and epoll just loves to report events for totally
@@ -482,6 +483,8 @@ events to filter out spurious ones, recreating the set when required. Last
not least, it also refuses to work with some file descriptors which work
perfectly fine with C<select> (files, many character devices...).
+Epoll is truly the train wreck analog among event poll mechanisms.
+
While stopping, setting and starting an I/O watcher in the same iteration
will result in some caching, there is still a system call per such
incident (because the same I<file descriptor> could point to a different