This is the mail archive of the cygwin-xfree@cygwin.com mailing list for the Cygwin XFree86 project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


----- Original Message -----
From: "Harold Hunt" <huntharo@msu.edu>
To: "Cygx (E-mail)" <cygwin-xfree@sources.redhat.com>
Sent: Tuesday, April 10, 2001 1: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 thought cygwin had fd support for keyboard and mouse? If it doesn't,
then my suggestion would be: write it.

> 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.

Just to be difficult: why not pthreads? mutex's, condition variables,
thread specific data, limited scheduling (soon to be much more) are all
present in snapshots at the moment. And they are thin wrappers around
win32. The advantage for you guys is you can probably leverage any
existing pthread written code. AND stay fork safe. Please, do not use
win32 threads in a cygwin1.dll linked application unless you are willing
to guarantee that you'll be single threaded when you fork, or at least
have your app understand that a fork is going to occur and that it has
to restart it's threads. Pthreads has a lovely function pthread_at_fork
that I'm hoping to implement soon which allows that syncronisation.

And I'll reiterate: This should be in cygwin1.dll. Don't fix the
symptom, fix the problem. Andif it's in cygwin1.dll you can use win32 or
unix threads to your hearts content (cygwin's internals already
understand syncronising after a fork.

> 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.

Sounds good. These would be acessed via /dev/mouse and /dev/keyboard.
(If it's in cygwin1.dll).

> 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
>


Rob>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]