On Tue, Oct 19, 2010 at 10:47 PM, Mike McCormack <mj.mccorm...@samsung.com> wrote: > On 10/19/2010 10:19 PM, Gustavo Sverzut Barbieri wrote: >> >> On Tue, Oct 19, 2010 at 11:16 AM, Mike McCormack >> <mj.mccorm...@samsung.com> wrote: >>> >>> Hi Guys, >>> >>> Superficially tested... issue is if somebody does: >>> >>> close(fd); >>> ecore_main_fd_handler_del(fdh); >>> >>> epoll can't remove the fd because it's already closed, so we get an EBADF >>> from the kernel. >>> Work around the broken case by issuing a WARN() and reinitializing ecore. >> >> WARN takes no trailing \n > > Ack. > >> other than that, why do we need to reinit it? Just let the fdh handle >> be removed from the list and never be considered anymore. I don't see >> why we need to reinit it. > > Because the fd *may* still be in the epoll array. If somebody happened > to dup() that fd, then the kernel will still have a filp hanging around > and the fd will not be automatically removed from the epoll set. The > kernel only automatically removes an fd from epoll when its filp is > destroyed, not when the fd (which is just a reference to the filp) is > closed. > > See the attached program for details. Kernel guys are aware of this, > and say that it works as designed...
seems weird, but okay. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
