From 942659ceb3ffc40845b9e6d4b886c6f09f76206b Mon Sep 17 00:00:00 2001 From: root Date: Sun, 31 Oct 2010 21:16:26 +0000 Subject: *** empty log message *** --- ev.pod | 13 ++++++++----- 1 file 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 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 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 work, but of course I, 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