/dev/windows and select() [was Re: Slow response to keypresses in xorg-server-1.8.0-1]

Jon TURNEY jon.turney@dronecode.org.uk
Mon Aug 30 14:11:00 GMT 2010


On 30/08/2010 12:23, Corinna Vinschen wrote:
> On Aug 29 14:39, Jon TURNEY wrote:
>> On 08/08/2010 12:04, Andy Koppe wrote:
>>> On 7 August 2010 23:07, Jon TURNEY wrote:
>>>> Hmmm, looking again at the implementation of select(), I don't immediately
>>>> see that when waiting on /dev/windows, it checks that the message queue has
>>>> old messages on it before waiting.  The MSDN documentation for
>>>> MsgWaitForMultipleObjects() seems to says that messages which had arrived
>>>> before the last PeekMessage() etc. aren't considered new and so don't end
>>>> the wait?
>>>
>>> I think you're right, a call to PeekMessage is needed for proper
>>> select() semantics: it shouldn't block if data is available for
>>> reading.
>>
>> Attached is a small test-case which seems to demonstrate this problem.
>>
>> Run ./dev-windows-select-test and observe select() blocks for the
>> full timeout, despite the fact that the /dev/windows fd is ready for
>> reading (and it reported as such as the end of the timeout)
>>
>> If you run './dev-windows-select-test -skip' to skip the
>> PeekMessage(), select() returns immediately, indicating the
>> /dev/windows fd is ready for reading.
>
> Again, thanks for the testcase.  I applied a patch to Cygwin which
> should make select on /dev/windows fully functional.
>
> The blessed solution is to replace the call to MsgWaitForMultipleObjects
> with a call to MsgWaitForMultipleObjectsEx with the MWMO_INPUTAVAILABLE
> flag set.  This flag is defined to do exactly what we need.
>
> The only downside is that this flag does not exist on NT4 and its usage
> results in an "invalid argument" error.  So, for NT4, I added the
> workaround I described in my yesterday's soliloquy.
>
> I'm planning to release Cygwin 1.7.7 tomorrow at the latest, so please
> give it a test as soon as possible.  Here's a binary DLL for testing
> (build w/o optimization, so it's probably a bit slow):
>
>    http://cygwin.de/cygwin-177/new-cygwin1.dll.bz2
>    (md5sum: 7e07fd9eafd021697a0861c1ae4fa94e)

Thanks Corinna :-)

I tried that cygwin DLL with my test case, and with an X server with what I 
now realize is the workaround I'd applied reverted [1] and it seems to work fine.

[1] 
http://cgit.freedesktop.org/~yselkowitz/xserver/commit/?h=cygwin-release-1.8&id=6da3190eacae2c2b021060f8fd9427816ac06f21

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple



More information about the Cygwin mailing list