On Fri, Apr 25, 2014 at 10:16:38AM +0300, Assaf Inbal <[email protected]>
wrote:
> You're right, using select or poll works as expected and only epoll is
> affected.
I've analyzed it, and indeed, this is a bug in the epoll backend generating
fake events. I'll fix it for the next release!
> The attached program was just a simple example to reproduce the issue. As
> I explained in the first mail, I have a library which works directly over
> FDs which (most of the time) are TCP sockets but occasionally are 'regular'
> files.
I read it, but what I said still applies - if you know it's files, then it
makes no sense using I/O watchers for it. If you don't know the type, then
libev should emulate for you.
> So, assuming that epoll is really the problem, I'm guessing I should look
> somewhere in epoll_poll(), specifically near the "now synthesize events for
> all fds where epoll fails" comment?
I'll take care of it, but indeed, that's the code that generates the
event. It does rely on the undocumented behaviour of EPOLL returning
eperm on regular files (but whats not undocumented in epoll...), but the
problem is caused by your watchers using the same fd, and while libev
removes the emulation for the fd on the first ev_io_stop, it doesn't add
it back on the next ev_io_start, which is a bug in not clearing the epoll
event mask (EV_EMASK_EPERM).
In any case, I understand the problem, and the only question is how to fix it
best. I'll notify you when I have a fix.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [email protected]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
