RE: Possibly incorrect explanation of how WaitForSomething works (and how to fix it) [RC and CGF please comment]

[Suhaib Siddiqi <ssiddiqi at inspirepharm dot com>]

 Harold,
You can feel free to remove the CYGWIN specific #ifdef from WaitFor.c, but
you need to test compile and test the binaries.  As I said before that code
was added for my xwin.exe which frooz always at startup on windows NT too.  

If your modifications to xwin works better with original WaitFor.c, sure why
not remove them.

Because you did major modifcations to Xwin source code therefore your
suggestions to mouse and keyboard sounds ok to me.  You need to change and
test?  Lately I had been too busy with projects at work and did not get time
to really dig into X sources and help you.  I do appreciate your
contributions.

Suhaib

-----Original Message-----
From: Harold Hunt
To: Cygx (E-mail)
Sent: 4/9/2001 11:27 AM
Subject: Possibly incorrect explanation of how WaitForSomething works (and
how to fix it) [RC and CGF please comment]

WaitForSomething, in xc/programs/Xserver/os/WaitFor.c, is supposed to
wait
for client requests, user input, ddx notifications, or something else of
interest that requires the X/Server to actually do something.
WaitForSomething passes a list of file descriptors to Select () that it
would like to wait for and it typically passes a timeout value of 2
minutes.

A normal unix-style operating system, like darwin, will have a file
descriptor that is used to read mouse and keyboard input; you use the os
layer function called AddEnabledDevice to add your input descriptor to
the
list of descriptors to be waited for in WaitForSomething.  As far as I
know,
Windows does not have file descriptors that become signaled when user
input
(via a Windows message queue, not via a console file descriptor) is
waiting.

Part of our problem, namely, the very slow input when removing the
#ifdef
__CYGWIN__'d sections from WaitForSomething, comes from not having a
file
descriptor that becomes signaled when user input is ready, thus we don't
have a way to return from Select when we have user input.  Currently our
user input is read by our screen WakeupHandler, which gets called by
WaitForSomething right *after* it returns from Select.  We've got a
catch-22
here :)

I propose the following modifications which should allow us to remove
the
#ifdef __CYGWIN__'d sections from WaitForSomething:
1) In hw/xwin/InitInput.c's InitInput (), create a new thread (with the
Win32 API, not pthreads) that processes the Windows message queue for
all
open X screens.
2) In hw/xwin/InitInput.c's InitInput (), open two localhost IP sockets
used
to signal when keyboard or mouse input is waiting.
3) In hw/xwin/winmouse.c's winMouseProc (), add a call to
AddEnabledDevice
(), passing the mouse signaling socket.
4) In hw/xwin/winkeybd.c's winKeybdProc (), add a call to
AddEnabledDevice
(), passing the keyboard signaling socket.
5) In hw/xwin/winwakeup.c's winWakeupHandler (), remove all code; we no
longer need to process our Windows message queue here.
6) In hw/xwin/winblock.c's winBlockHandler (), remove all code; we no
longer
need to process our Windows message queue here.
7) In os/WaitFor.c's WaitForSomething (), remove all #ifdef __CYGWIN__'d
sections.

After the above modifications we should have an input thread that is
independent of the server thread and we will use a socket to signal when
user input is ready, thus WaitForSomething's Select call will return in
a
timely fashion when user input is waiting to be processed.

Off the top of my head I can only think of two synchronization issues:
1) hw/xwin/InitInput.c's ProcessInputEvents () and
hw/xwin/winwndproc.c's
winWindowProc () must use a mutex so that the window procedure doesn't
try
to add input events while ProcessInputEvents is trying to remove them.
2) hw/xwin/winwndproc.c's winWindowProc () and winshad*.c's
winShadowUpdate*
(), where * is DD, DDNL, or GDI, must use a mutex so that both
procedures do
not try to blit the shadow buffer to the screen at the same time.  Of
course, DirectDraw may be reentrant, so this may not be a problem;
however,
it would be cleaner and clearer to future contributers if we added our
own
mutex.

I'm not saying that this will fix the freeze on startup that some users
experience, nor am I implying that it will fix the crash on closing
certain
clients; however, I will imply that these modifications will allow us to
clean up os/WaitFor.c to make it independent of __CYGWIN__.

Give me some feedback on this one,

Harold