Help with fixing x2x...

[Thomas Chadwick]

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