On Tue, Oct 28, 2008 at 12:45:07PM +0300, Kandalintsev Alexandre <[EMAIL PROTECTED]> wrote: > >I just found another bug in epoll > Did you try to contact kernel developers about this problem?
The kernel developers are not interested in fixing epoll. (I tried a year ago for similar issues, fork races, and the samba and postfix authors were similarly being ignored, so on linux, we have the choice between the totally misdesigned epoll API or select/poll, I wish for somethign comparatively sane as kqueue). I realised we need some kind of token protection anyways in case of fork - basically, with epoll, you have to recreate the epoll handle in both parent and child after a fork (or do even slower things before the fork). Now, libev did explain that you can get spurious notificagtions (solaris event ports cause those too, for example), the crucial difference is that I thought it would be possible to cope with them easily in application code, but recently realised you can't do that portably for nonblocking connects (maybe not even nonportably - I don't know how to check for whether a connection is currently in progress or not except by trying another connect or so). To me, the remaining question is just whether I should extend the ANFD structure with 32 bits of generation count, or whether I can go with the 8 bit currently implemented (which are free): Extending a structure from 8 to 12 bytes sucks, especially on ia32. I also think about about forcing the use of pthread_atfork (or the internal __register_atfork) on linux, to catch forks for the parent (the child is easy, getpid has virtually no cost, so forcing a getpid call per loop iteration would not concenr me at all, but that doesn't work for the parent process). I also still think of ways on how to avoid the epoll set recreation in the parent (for 10000 fds this means 10001 syscalls...), but I can't come up with anything that would be practically useful. -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=====/_/_//_/\_,_/ /_/\_\ _______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev