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]
Other format: [Raw text]

Re: Help with fixing x2x...


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


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