Re: Chris: message queues and new windows (was select() details)

[Christopher Faylor <cgf at redhat dot com>]

On Wed, Apr 11, 2001 at 02:03:46PM +1000, Robert Collins wrote:
>> -----Original Message-----
>> From: Pierre A. Humblet [mailto:Pierre.Humblet@ieee.org]
>> Sent: Wednesday, April 11, 2001 1:29 PM
>> To: cygwin-xfree@cygwin.com; cygwin-xfree@cygwin.com
>> Subject: Re: Possibly incorrect explanation of how WaitForSomething
>> works (and how to fix it) [RC and CGF please comment]
>> 
>> 
>> Chris,
>> 
>> I am currently trying to understand select().
>> I see the following in the code:
>> ****************
>> peek_windows (select_record *me, int)
>> {
>>   MSG m;
>>   HANDLE h;
>>   set_handle_or_return_if_not_open (h, me);
>> 
>>   if (me->read_selected && me->read_ready)
>>     return 1;
>> 
>>   if (PeekMessage (&m, (HWND) h, 0, 0, PM_NOREMOVE))
>>     {
>>       me->read_ready = TRUE;
>>       select_printf ("window %d(%p) ready", me->fd, 
>> me->fh->get_handle ());
>>       return 1;
>>     }
>> ***************
>> What is this used for?
>
>That appears to be part of poll(), not select(). Check out
>msdn.microsoft.com for doco on PeekMessage. (ie   
>
><http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/winui/m
>essques_8085.htm>
>
>The select() call uses WaitForMultipleObjects, which is the correct
>method for getting woken up when input arrives. Someone needs to debug
>(perhaps with an event queue watcher) what is happening with the X
>server. 

Oops.  Correct.

>strace is a wonderful tool - I recommend using it as well :].
>
>I haven't read the code for the X Server, but as the X server creates
>it's own window, keyboard and mouse messages for it will arrive in a
>different message queue than the cygwin select() call looks at.
>
>What needs to happen (as Harold as already noted) is that these messages
>need to be processed rather than waiting for the cygwin select() to
>return, which is only prompted by network traffic.

Are you saying that X-Windows is not adding windows handle events to its
select() call?  It sounds like an obvious win to do this.

Then, polling of the network connections wouldn't be necessary.  I don't
know why there would be any newly opened connections hanging around
after select is called, though.  If there are, that is an obvious huge
bug.

>There are two basic ways to do this:
>async - spawn a new thread, that waits on the window queue and prepares
>to handle and process the events
>sync - inform cygwin of the new message queue in some fashion, and have
>select() wait on it as well.
>
>Harold has already thought out most of the issues with the async
>fashion. I suspect that syncronisation will be harder than expected, but
>then I'm a pessimist. 
>
>For the sync way, I dont' know of any standard way to tell cygwin that a
>new message queue exists and should be treated as a keyboard/moure input
>queue. 
>
>Chris: a question for you
>
>Is there some unix similar way that we could do that? I.E. a
>/dev/keyboard and /dev/mouse that take a window identifier of some sort
>in the open call. Or let it get set via fcntrl? That would allow the X
>server to stay 100% unix coded - sitting on a single event loop. It
>would also allow the X server to recieve Cygwin style signals properly,
>which I suspect it may not if they enter via the wrong message queue...

Why not, for now, just open /dev/windows and select for that?  If the event
is a keyboard or mouse event then handle them, otherwise go back to waiting.

I'm not aware of any /dev/keyboard analog in Windows.  There are obviously
/dev/mouse type of devices, though.  Usually, they are just a serial device
or a specific PS mouse port, though.

Implementing either of these, in a windows context, wouldn't be too hard,
though.  I would like to make sure that we got the implementation as close
to Windows as possible, though.

cgf