On Fri, Aug 29, 2014 at 12:07:57AM +0200, Hongli Lai <[email protected]> wrote:
> With "lost" I do not mean that libeio closes it. I meant that the file
> descriptor still exists, but nobody knows what its number is.
Since libeio doesn't own the fd, somebody else must own it, e.g. your
program. If your program no longer knows what fd to close when the request
is destroyed, it can probably look at the request or, usually better, it
really should know - how would you know the data ptr in the request is
still valid for example?
> When ETP_FINISH sees that the cancel flag is 1, and returns, where did
> the file descriptor number go?
Nowhere, libeio simply doesn't own the fd, so its not responsible for
closing it. If you cancel a request but forget about it before it is
destroyed, then you need to change your program, *or* you can check the
cancel flag in the destroy callback.
> How can one close it now that the
> callback will not be called?
Depends on your program. In IO::AIO, it's closed in the destroy callback
because it decrements the reference counter (for filehandles), or not
at all (if the user passed an fd number, ikn which case the user is
responsible).
I can see a possible complication for eio_open calls and other calls, but
in all cases, you have to know whether the fd is still needed, and close
it otherwise.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [email protected]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
