PATCH: Get rid of superfluous dup() and close() calls.

Martin Wilck Martin.Wilck at Fujitsu-Siemens.com
Tue Feb 11 04:37:47 CST 2003


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

-- 
Martin Wilck                Phone: +49 5251 8 15113
Fujitsu Siemens Computers   Fax:   +49 5251 8 20409
Heinz-Nixdorf-Ring 1	    mailto:Martin.Wilck at Fujitsu-Siemens.com
D-33106 Paderborn           http://www.fujitsu-siemens.com/primergy








More information about the wine-devel mailing list