Browse Source

*** empty log message ***

master
Marc Alexander Lehmann 11 years ago
parent
commit
35b9f60ff5
  1. 13
      ev.pod

13
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

Loading…
Cancel
Save