io watcher: how to catch close(fd) after starting watcher

Marc Lehmann schmorp at
Thu Nov 8 22:12:48 CET 2012

On Thu, Nov 08, 2012 at 06:37:19PM +0100, Jan-Philip Gehrcke <jgehrcke at> 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_    
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at
      -=====/_/_//_/\_,_/ /_/\_\

More information about the libev mailing list