Hello,
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,
Jan-Philip
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
