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