I/O Completion Ports Implementation

Robert Shearman R.J.Shearman at warwick.ac.uk
Tue Nov 11 18:33:54 CST 2003


> -----Original Message-----
> From: Alexandre Julliard [mailto:julliard at winehq.com]
> Sent: 12 November 2003 00:06
> To: Robert Shearman
> Cc: wine-devel at winehq.org
> Subject: Re: I/O Completion Ports Implementation
>
>
> "Robert Shearman" <R.J.Shearman at warwick.ac.uk> writes:
>
> > WaitForSingleObject(hIoCompletion, INFINITE) returns straight away with
> > WAIT_OBJECT_0 on Windows. Using it would break this behaviour (which of
> > course any sane apps would not depend on).
>
> I must be missing something, but I don't see how your code can do
> that.

In remove_io_completion:

+        port->satisfied = 0; /* don't abandon wait on the port */
+        select_on(1, req->cookie, &req->handle, SELECT_TIMEOUT,
&req->timeout);
+        port->satisfied = 1; /* abandon any waits on the port immediately
*/

Maybe it's a bit of a hack, but I assume this behaviour won't change any
time soon: select_on only checks if the object is satisfied when it is first
called and waits for manual notification that the object has been satisfied
once the select_on call has succeeded. Therefore I set the flag to say that
it isn't satisfied before calling select_on so that the select_on call will
actually make the thread sleep and then set the flag back afterwards so that
the behaviour is present of returning immediately because it is satisfied.

> You are waiting on the handle anyway so the behavior will be
> the same if you use WaitForSingleObject. If that is not supposed to
> work then you need to create another object to wait on, and that's
> true whether you use WaitForSingleObject or not.

This is what I originally did, but I ended up having to duplicate
functionality from most of server/thread.c to achieve it. I thought this new
way would be somewhat cleaner (and the patch is indeed a lot smaller).

Rob





More information about the wine-devel mailing list