> -----Original Message----- > From: Alexandre Julliard [mailto:[EMAIL PROTECTED] > Sent: 12 November 2003 00:45 > To: Robert Shearman > Cc: [EMAIL PROTECTED] > Subject: Re: I/O Completion Ports Implementation > > "Robert Shearman" <[EMAIL PROTECTED]> 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
