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 new coding rule (after removing the dup) is very simple:
** Never close() a Unix fd that you haven't open()d or dup()d ** yourself.
Actually, one could formulate it more clearly:
** Never call close() unless you really know what you're doing.
That is easy to understand for everybody, I reckon. I think it is much more likely that a programmer forgets a close() call than that he erroneously writes one, especially because it is pretty hard to even find the hidden dup() that creates all these fd's. When I was new to wine I guess it took me least a week to understand why the close() calls appeared everywhere.
The current rule is much more complex. Especially with asynchronous IO it becomes *very* hard to track the open fd's.
Please rethink your position on this subject.
Martin