On Thu, Nov 08, 2012 at 06:37:19PM +0100, Jan-Philip Gehrcke
<jgehr...@googlemail.com> wrote:
> I'm working on Linux 2.6.32. Consider the case where a file
> descriptor is closed at some point *after* starting an IO watcher on
> this certain file descriptor. How should the watcher behave in the
> moment of closure?
Having a watcher on a nonexistant file descriptor is a bug in the program,
and libev has no prescribed behaviour for that.
> From here, I still don't understand what the intended watcher
There isn't any intended behaviour, anything goes. Effectively you run
into undefined behaviour.
> "Some backends (e.g. kqueue, epoll) need to be told about closing a
> file descriptor (either by calling close explicitly or by any other
> means, such as dup). The reason is that you register interest in some
> file descriptor, but when it goes away, the operating system will
> silently drop this interest."
>
> I call close explicitly (Python's os.close(fd) uses on POSIX
> close(fd)), so am I not already following this advice?
close does not tell epoll anything (and even if, epoll isn't libev) - what
that sentence means is that close is not the only function that closes
file descriptors.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
