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

Jan-Philip Gehrcke jgehrcke at
Thu Nov 8 18:37:19 CET 2012


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?

In a libev-based Python library I am using, it looks like the watcher 
does not detect the closure. As EV_READ or EV_WRITE are obviously never 
triggered again after close(), in this special case, the result is a 
read function that never returns. I would expect an Exception to be thrown.

I was going through the libev docs in order to find out if the IO 
watcher is able to detect the closure. I read about EV_ERROR:

"an unspecified error has occured, the watcher has been stopped. This 
might happen because the watcher could not be properly started because 
libev ran out of memory, a file descriptor was found to be closed or any 
other problem."

 From here, I still don't understand what the intended watcher behavior 
is in the described scenario: should the watcher stop immediately 
setting EV_ERROR (which would be detectable in the Python library) or is 
the watcher simply unable to detect the closure (in which case I am 
wondering if there are alternative ways to automatically stop a watcher) 
and continues waiting for EV_READ, EV_WRITE?

Regarding alternative ways, I also read:

"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?

Thanks for your help,


More information about the libev mailing list