Help with fixing x2x...

Wed Jul 24 12:18:00 GMT 2002

I added a printf statement and sure enough, the return value of select is 
-1.  I then tried printf'ing the value returned by WSAGetLastError.  To make 
a long story short, I wound up having to comment out the includes for 
<sys/types.h> and <sys/time.h> and include <w32api/winsock.h> instead to get 
it to succesfully compile x2x.o; and I had to add -lwsock32 in the Makefile 
to get it to successfully link x2x.exe.

After doing this, select is still non-blocking, returning -1, and the value 
returned by WSAGetLastError() is 10038, which seems to correspond to the 
#define WSAENOTSOCK in winsock.h.

Any idea what this error code means and what steps I might take to fix it?

>From: "Jean-Claude Gervais" <jc.gervais@videotron.ca>
>Reply-To: cygwin-xfree@cygwin.com
>To: <cygwin-xfree@cygwin.com>
>Subject: RE: Help with fixing x2x...
>Date: Wed, 24 Jul 2002 11:58:41 -0400
>
>Have you checked what select is returning?
>I remember there were differences in how an FD_SET was used in Win32 and
>UNIX.
>
>Also, since select is probably returning -1, call WSAGetlastError and check
>what the code is.
>
>
>-----Original Message-----
>From: cygwin-xfree-owner@cygwin.com 
>[mailto:cygwin-xfree-owner@cygwin.com]On
>Behalf Of Thomas Chadwick
>Sent: Wednesday, July 24, 2002 11:41 AM
>To: cygwin-xfree@cygwin.com
>Subject: 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

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com