This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Re: Help with fixing x2x...
- From: "Thomas Chadwick" <j_tetazoo at hotmail dot com>
- To: cygwin-xfree at cygwin dot com
- Date: Wed, 24 Jul 2002 11:41:08 -0400
- Subject: Re: Help with fixing x2x...
- Bcc:
- Reply-to: cygwin-xfree at cygwin dot com
Hmmm. I tried your suggestion and the behavior has not changed. It's
still gobbling up 99% of the CPU. Suspecting that select() is not blocking
like it should, I inserted "printf("Hello\n");" just before the select()
function call. Now when I run x2x I get a continuous stream of "Hello"s on
STDOUT whether or not I'm moving the mouse or typing.
By comparison, I compiled x2x on my AIX workstation, including the "Hello"
addition. When I run x2x there, I observe that it only prints "Hello" when
I move the mouse or hit a key. This seems to me to be the appropriate
behavior.
This little experiment implicates the select() function call itself as being
the source of the trouble. Now the question is, is it a problem with how
select() is being used (and if so, is the problem at the Xserver or the
Xclient end), or is there a problem with the Cygwin implementation of it?
Are you aware of any Xclients which use select() and yet do not exhibit the
non-blocking behavior I'm seeing? Perhaps there is a minor tweak required
in how it is being called.
From: Harold L Hunt II <huntharo@msu.edu>
To: Thomas Chadwick <j_tetazoo@hotmail.com>
CC: cygwin-xfree@cygwin.com
Subject: Re: Help with fixing x2x...
Date: Tue, 23 Jul 2002 18:58:15 -0400
Thomas,
In x2x, the return value from ProcessEvent which indicates that everything
went normally is False, not True. The real intentions for the return value
of ProcessEvent can be described by the boolean variable called
``bAbortedDisconnect'' that is returned from ProcessMotionNotify. Much
more on that below but for now,
Ohmygodthatisfunny!!!
In the loop, the code does this:
1) Check for an event on fromDpy. XPending returns immediately.
2) Process the event for fromDpy if an event was pending. If we processed
an event successfully, continue looping. Else, the ProcessEvent function
returned True and we are supposed to shutdown, thus the ``break''.
3) Check for an event on toDpy. XPending returns immediately.
4) Process the event for toDpy if an event was pending. If we processed an
event successfully, continue looping. Else, the ProcessEvent function
returned True and we are supposed to shutdown, thus the ``break''.
5) Else, if we did not process an event from either screen, wait until one
or both o fthe file handles that represent the display event queues becomes
ready for reading.
I think that your infinite loop has to do with the fact that XPending
returns a count of events ready for reading in fromPending, rather than a
boolean value. I think that (!fromPending) had the desired effect on the
developer's platform of determining that (fromPending == 0), but that is a
highly compiler-dependent assumption on behalf of the original developer.
For clarity, I would rewrite the section as follows (notice the correction
in the ``else if''):
====================================================================
while (True) /* FOREVER */
{
/* Save the number of event ready for fromDpy */
fromPending = XPending(fromDpy);
/* Process any events ready for fromDpy */
if (fromPending != 0)
if (ProcessEvent(fromDpy, &dpyInfo)) /* shutdown if True! */
break;
/* Process any events ready for toDpy */
if (XPending(toDpy))
{
if (ProcessEvent(toDpy, &dpyInfo)) /* shutdown if True! */
break;
}
else if (fromPending == 0)
{
/* No events ready for either display. Wait for an event. */
FD_ZERO(fdset);
FD_SET(fromConn, fdset);
FD_SET(toConn, fdset);
select(nfds, fdset, NULL, NULL, NULL);
}
} /* END FOREVER */
====================================================================
Now, for the excitement about the bAbortedDisconnect variable from
ProcessMotionNotify:
It looks like the original programmer is using some sort of consistency
checking on MotionNotify events to determine that the X server is shutting
down. I will have to look into this further, but it looks promising from
my initial inspection. This is the final step that I need for xwinclip to
function properly on server resets and shutdowns. Needless to say,
hopefully I am seeing what I want to see :)
Harold
Thomas Chadwick wrote:
I recently discovered that when I run x2x, the Win2k Task Manager reports
that it's using 90-99% of the CPU.
While I have not noticed a slow down in performance when it's running, I'd
like to fix it if I can. I've poked around in the source and I don't like
the looks of the main loop:
while (True) { /* FOREVER */
if (fromPending = XPending(fromDpy))
if (ProcessEvent(fromDpy, &dpyInfo)) /* done! */
break;
if (XPending(toDpy)) {
if (ProcessEvent(toDpy, &dpyInfo)) /* done! */
break;
} else if (!fromPending) {
FD_ZERO(fdset);
FD_SET(fromConn, fdset);
FD_SET(toConn, fdset);
select(nfds, fdset, NULL, NULL, NULL);
}
It would appear to me that this constant polling for an event to process
is what's eating up the CPU cycles.
Not being an X programmer, I'm hoping someone monitoring the list can
suggest a way to modify this loop to be less of a CPU hog.
Thanks.
_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx
_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com