I couldn't resist so I kept investigating. It seems the problem is not specific to XSync -- I tried removing all calls to XSync and XSynchronize in xboard.c. The problem magically moved over to the XSetArg calls in ModeHighlight(). I commented those calls out, and the problem magically moved to the XGetWindowAttributes() call in CreateAnimVars().
So my conclusion is that my system is just taking a very long time to execute whatever happens to be the first call to xlib during a particular execution. I imagine it'll be very hard for xboard developers to magically intuit what part of my system is causing that particular problem -- it doesn't seem to be xboard-specific although no other program on my machine has this issue -- so I'll stop bugging this list about it unless somebody has a brilliant flash of insight :) Which would be very much appreciated. Thanks guys! -Adrian On Wed, Aug 4, 2010 at 11:54 AM, Adrian Petrescu <[email protected]> wrote: > By the way, sorry for the double-post, but I really should mention, only > the first two calls to XSync during the lifetime of XBoard (once right after > it draws the board, and once right after it draws the menus at the top for > the very first time) are slow. All subsequent calls are perfectly normal and > the two prints come out instantly one after the other. > > Cheers, > Adrian > > > On Wed, Aug 4, 2010 at 11:52 AM, Adrian Petrescu <[email protected]>wrote: > >> Hello :) >> >> Thanks for the response. I did a bunch of testing and I've pinpointed the >> problem: it seems the call to XSync is extremely slow. On line 4568 of >> xboard.c if I do: >> >> printf("About to call XSync\n"); >> XSync(xDisplay, False); >> printf("Done calling XSync\n"); >> >> Then the "About to call XSync" gets printed right before the long, painful >> hang, and "Done calling XSync" gets called right when it recovers. The two >> prints are about 10 seconds apart. So I think this is definitely the issue. >> >> Unfortunately I'm not very familiar with low-level X programming to be >> able to diagnose this right away -- it's way before my time :) I'll take >> more of a look if nobody here knows what might be the cause off the top of >> their heads. >> >> Cheers, >> Adrian >> >> On Wed, Aug 4, 2010 at 5:53 AM, h.g. muller <[email protected]> wrote: >> >>> At 22:33 3-8-2010 -0400, Adrian Petrescu wrote: >>> >>>> Here is a strange symptom that may illuminate the issue or make it more >>>> puzzling. You decide which. >>>> >>> >>> This will indeed be a tough cookie... >>> >>> For me, startup of XBoard under Ubuntu is fast, so I cannot test it >>> myself. >>> >>> It sounds like XBoard is making a system request that your system has big >>> trouble in satisfying. >>> What are you seeing durng these 10 seconds? Is the XBoard main window >>> already up, and >>> is the Chess board properly displayed? Are any of the auxiliary windows >>> already up? >>> The most passive mode to bring XBoard up in is -ncp (with -ics you might >>> still hang because >>> of connection problems with the ICS), so perhaps you should always test >>> on that. >>> >>> Could you start XBoard with the -debug option? This should make a file >>> xboard.debug, >>> and if we are lucky, we can establish from that where it hangs. I think >>> it does print some >>> progress reports during the startup process, from main() in xboard.c. If >>> not, we should >>> add some fprintf(stderr, "..."); there to figure out where it hangs. >>> There are no time stamps >>> with debug messages from XBoard itself, though. So to see where it hangs, >>> it might be >>> necessary to kill it during those 10 sec. >>> >> >> >
_______________________________________________ Bug-XBoard mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-xboard
