Martin Wilck Martin.Wilck@Fujitsu-Siemens.com writes:
Am Fre, 2003-01-31 um 22.37 schrieb Alexandre Julliard:
I think it's cleaner to return a dup of the fd instead of relying on the fact that the fd is cached internally. This may not always be the case, and it's better to risk an fd leak than to risk invalidating the cached value in case someone closes the fd when they shouldn't.
I see your point, but I don't see the risk you're talking about.
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.
The current rule is much more complex. Especially with asynchronous IO it becomes *very* hard to track the open fd's.
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.