I/O Completion Ports Implementation

[Robert Shearman]

> -----Original Message-----
> From: Alexandre Julliard [mailto:julliard at winehq.com]
> Sent: 12 November 2003 00:45
> 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:
>
> > 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.
>
> OK, I guess you meant to use the signaled() method instead of
> satisfied() (the satisfied method is used to cleanup after the wait
> has succeeded, so it's not what you want here). But it still wouldn't
> work properly, since it's possible that we'll check the wait condition
> again later on while the thread is sleeping (for instance if the
> thread gets suspended) and it would then return a spurious signaled
> condition. You should really use the proper wait mechanisms instead of
> trying to subvert them that way.

Yes, you are right. Satisfied only works in the SELECT_ALL case.

> > 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).
>
> I don't see why you'd need to duplicate anything. Just create another
> object, like an event, and return that in remove_io. Then the client
> can simply do a WaitForSingleObject on the event.

Ok, I hadn't thought of doing it that way :)

Rob