Am Don, 2003-02-06 um 22.17 schrieb Alexandre Julliard:
The risk is a detail, the real point is that an API that returns an fd to a client has to return a new fd and let the client close it, since we can't know when the client is finished with it. Currently because of the fd cache it happens that we don't really need the close() but that's an implementation detail that could change; and we need to keep the flexibility to change it.
It is not clean to hide the system call that creates the fd and require the client to make the call that destroys it.
It'd be better to have the client call wine_server_get_fd() (as now) to get the fd and wine_server_release_fd() if it's done with it. Then it'd be entirely up to wine core functionality whether or not get_fd()/release_fd() requires a dup() and a close().
That'd be much better than what we have now, and keep the flexibility you're talking about. Instead of doing dup() and close(), we could have a usage count associated with a Unix fd.
Can we come to an agreement along these lines?
I don't see why it would be hard to close fds, it's just standard resource management, like freeing allocated memory, etc. If the async I/O code makes this hard to do then the code is broken.
Asynchronous IO, broken or not, allows for hundreds of simultaneous IO operations on a single HANDLE, and therefore gets us into *resource shortage* as long as we use up an fd for each such operation.
Martin