UCCI2WB

[JoshPettus]

Thanks that seems to work

I'm afraid I don't see any quit command.

Code: Select all

command read: xboard

command read: protover 2

command read: option UCI2WB debug output=1

command read: option promotion=0

command read: option batch=0

command read: option debug=0

command read: option usehash=1

command read: option usebook=1

command read: option bookfiles=./BOOK.DAT

command read: option idle=none

command read: option pruning=none

command read: option knowledge=none

command read: option randomness=none

command read: memory 68

command read: cores 1

command read: new

command read: random

command read: variant xiangqi

command read: level 40 5 0

command read: post

command read: hard

command read: easy

command read: ping 1

command read: accepted variants

command read: accepted setboard

command read: accepted usermove

command read: accepted debug

command read: accepted ping

command read: accepted reuse

command read: accepted exclude

command read: accepted pause

command read: accepted done

command read: accepted option

command read: accepted myname

command read: accepted option

command read: accepted option

command read: accepted option

command read: accepted option

command read: accepted option

command read: accepted option

command read: accepted option

command read: accepted option

command read: accepted option

command read: accepted option

command read: accepted smp

command read: accepted memory

command read: accepted done

command read: time 30000

command read: otim 30000

command read: usermove g0e2

command read: time 29979

command read: otim 29626

command read: usermove b2b6

[EDIT]

Interesting when I quit from the menu xboard never gets a chance to send xboard {exit} and quit in the debug file. (and as shown in UCI.debug log above) But all engines, xboard, uci, polyglot, seem to quit anyway (minus eleeye). I take it this is some OS quit command interrupting xboard. GPS shogi quits anyway.

But when I quit via closing the window it does send the quit command, but I don't get any output in the UCI.debug. really weird. I have no idea whats going on there. GPSShogi quits in either case. Does USI protocol make it quit when it looses contact with UCI2WB?

[hgm]

Hmm, it doesn't seem like XBoard pays attention to -delayAfterQuit.

Try in backend.c, near line 11471, to add an extra DoSleep like this:

Code: Select all

	if (first.pr != NoProc) {
	    ExitAnalyzeMode();
            DoSleep( appData.delayBeforeQuit );
	    SendToProgram("quit\n", &first);
            DoSleep( appData.delayAfterQuit );
	    DestroyChildProcess(first.pr, 4 + first.useSigterm);
	    first.reload = TRUE;
	}

and some 27 lines later the same for the second engine.

[JoshPettus]

Maybe, I'll give it a try, but it hangs a little bit when I quit via closing window. (which suggests It works) But not when I go to the quit menu. And there is a difference in output in the debug file. Closing window I see a quit sent, Closing via menu, there is none.

[JoshPettus]

Same results . I don't know. maybe you might have to force it or try sending bye first. who knows it might work. I wish I could get another working UCCI engine to see if this is a protocol problem or eleeye one.

[hgm]

It could be that the Apple quit menu preempts us. Wasn't that one of the menu items we had to suppress in XBoard because it was a standard Apple item?

[Edit] I remembered right. In gtk/xoptions.c we have

Code: Select all

#ifdef OSXAPP
	if(!strcmp(msg, "Quit ")) continue;             // Quit item will appear automatically in App menu
	if(!strcmp(msg, "About XBoard")) msg = "About"; // 'XBoard' will be appended automatically when moved to App menu 1st item
#endif

So it is very nice that Apple provides us with a stock 'Quit' menu item, but it does not do the same as the original XBoard 'Quit' item. The latter nicely closes down the engine, auto-saves the game in progress, etc. Seems the Apple Quit just instantly kills the process.

Probably OSX sends the process some signal that it intends to kill us soon, and we would explicitly have to catch that signal, and connect it to XBoard's ExitEvent().

[JoshPettus]

That's my assumption too, but closing the window goes through the whole xboard closing event, and that has the same issue. And until now, it hasn't been much of a problem. UCI USI and xboard engines close fine in both cases. Whats different about UCCI that keeps it open? I take it closes for you in windows? Have you compiled Eleeye on linux see if that has similar issues? It may not be ideal, but wouldn't it be easier to just tell UCI2WB on termination to killall engine for #ifdef __apple__?

[JoshPettus]

Ah, It doesn't generate or update the user conf file as is. We might have to fix that bug after all... (evidently I close the window normally)

[Edit]
here is the relevant part in gtk-mac-integration

https://github.com/jralls/gtk-mac-integ ... #L261-L262


that (action: @selector (terminate: ) is the command it sends to the OS

This guy says quit is not a signal but an apple event..
http://superuser.com/questions/480259/w ... t-commands
--------------
What if I disabled that quit item in gtk-mac-integration and we use our own?
I already have my own version with a few changes to make localization work, Doesn't look like the maintainer will make the fix anyway. For now in the "About" item, I actually commented out the section that added an extra xboard, and removed that line that removed the extra "xboard" to fix the string for gettext. I haven't decided what to do about these changes yet.

[hgm]

Try to modify this line in GUI2Engine:

Code: Select all

	line[++i] = 0; if(x == EOF) { printf("# EOF\n"); exit(-1); }

to

Code: Select all

	line[++i] = 0; if(x == EOF) { fprintf(toE, "quit\n"); fprintf(dbg, "EOF; quit sent\n"); printf("# EOF\n"); exit(-1); }

Explanation:

The GUI2Engine thread is waiting for input from the GUI, but if XBoard is killed by OSX the pipe breaks, and UCI2WB will read an end-of-file code from it. It was then exiting, but without notifying the engine.

With this change it sends 'quit' to the engine also in this case (and reports in the uci.debug file).

This would of course not solve the problem of XBoard not saving games and settings and such. But it might prevent hanging engines.

[Edit] Oh, and in XBoard try to add in gtk/xboard.c, the #ifdef OSXAPP block at the beginning of main(), just below:

Code: Select all

	g_signal_connect(theApp, "NSApplicationOpenFile", G_CALLBACK(StartNewXBoard), NULL);

Code: Select all

	g_signal_connect(theApp, "NSApplicationWillTerminate", G_CALLBACK(ExitEvent), NULL);

[JoshPettus]

Ah ok, I'll give your idea a try first.

[hgm]

I guess the DoSleep chance was pointless: XBoard already payed attention to -delayAfterQuit after all; I just overlooked it. It was inside usystem.c:DestroyChildProcess().

But I guess UCI2WB should really protect itself against immediate forceful killing by the SIGTERM that XBoard sends after quit, (to wake up a pondering or thinking GNU Chess and make it observe the quit command), as this will kill it while it still most shut down the engine. So change the line

Code: Select all

        { pthread_t t; signal(SIGINT, SIG_IGN); pthread_create(&t, NULL, Engine2GUI, NULL); }

in UCI2WB to

Code: Select all

        { pthread_t t; signal(SIGINT, SIG_IGN); signal(SIGTERM, SIG_IGN); pthread_create(&t, NULL, Engine2GUI, NULL); }

which should make it resistant to SIGTERM, and quit in its own time.