diff options
| -rw-r--r-- | ev.pod | 13 |
1 files changed, 8 insertions, 5 deletions
@@ -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 |