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" <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: <[EMAIL PROTECTED]> >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: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED]]On >Behalf Of Thomas Chadwick >Sent: Wednesday, July 24, 2002 11:41 AM >To: [EMAIL PROTECTED] >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 <[EMAIL PROTECTED]> > >To: Thomas Chadwick <[EMAIL PROTECTED]> > >CC: [EMAIL PROTECTED] > >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
