Re: UCI2WB 4.0
Posted: Sun Dec 23, 2018 1:14 pm
Being idle, waiting for commands. I.e. not searching.
Irrelevant. The adaptor should work even with engines that don't exist yet so that their implementation is not known now. Btw., there is one corncer case where even buffering will cause trouble, and that's if setoption is used for variants like Chess960 where the chess rules are modified. If GUI and engine don't agree on the applicable chess rules that the "bestmove" should adhere to, that will cause issues.Do you know any engine which will not handle the sequence of commands I posted?
In case the stream is a file, then anything could go wrong. Disk full, disk removed, network connection down with remote files. With stdout as stream, that would only be if the pipe breaks, i.e. if the receiving program has exited. But that is already checked here I think:
Code: Select all
if(!fromF && !ReadLine(fromE, line)) printf("tellusererror UCI2WB: %s died on me\n", binary), exit(0);
I don't get this. Surely it should not be possible to change variant while the engine is thinking. The variant should already be known whenever a search is started. Or even when the position is set up, as otherwise you would not know what 'startpos' means, or how to parse the FEN.Ras wrote: ↑Sun Dec 23, 2018 2:17 pmBtw., there is one corncer case where even buffering will cause trouble, and that's if setoption is used for variants like Chess960 where the chess rules are modified. If GUI and engine don't agree on the applicable chess rules that the "bestmove" should adhere to, that will cause issues.
That is what I thought. Of course it would be theoretically possible that an engine just closes stdin, but leaves stdout open, so that reading from the engine would not detect it. But that is in principle not different from the engine simply refusing to read from the pipe, (or ignore what it reads), which could not be checked from fprintf. So it seems pointless to test for this special case (which looks more like a poorly executed attempt at sabotage anyway...).In case the stream is a file, then anything could go wrong. Disk full, disk removed, network connection down with remote files. With stdout as stream, that would only be if the pipe breaks, i.e. if the receiving program has exited. But that is already checked here I think:
Code: Select all
if(!fromF && !ReadLine(fromE, line)) printf("tellusererror UCI2WB: %s died on me\n", binary), exit(0);
Sure, but if the variant is changed via setoption while the engine is searching, then there are two possibilities if the engine doesn't outright discard setoption:
I agree on both points. It is generally suggested that it is a "very bad idea"(tm) to fclose stdin except right before terminating the application because it would mess with the file descriptors. Even for remapping stdin/out/err, freopen instead of an fclose/fopen is suggested.But that is in principle not different from the engine simply refusing to read from the pipe, (or ignore what it reads), which could not be checked from fprintf. So it seems pointless to test for this special case (which looks more like a poorly executed attempt at sabotage anyway...).
You should check all the I/O!!hgm wrote: ↑Sun Dec 23, 2018 2:40 pmCode: Select all
if(!fromF && !ReadLine(fromE, line)) printf("tellusererror UCI2WB: %s died on me\n", binary), exit(0);
Let's stop here.
I agree to that, but that was not the question. Please re-read what the discussion with buffering setoption actually was about.
Finally got around to testing this patched v4 version again with Leela (lc0.exe).hgm wrote: ↑Fri Dec 21, 2018 5:21 pm OK, I uploaded a patched version. Compared to 4.0 this has 2 extra features for prevending hanging engine processes:
1) An extra 'quit' command will be sent to the engine directly from the GUI thread (bypassing the command queue, which might be blocked while waiting for the engine) about 500msec after a quit command is received. This solves the problem for engines that take a long time to initialize (so that the engine thread is tied up waiting for 'uciok'), when we want to quit them during initialization.
2) A second 'new' command to the same UCI2WB run will now skip the 'isready' handshake. Since UCI2WB specifies feature reuse=0 such a second 'new' should never be needed, but WinBoard spuriously sends one just before it quits the engine to launch a new one. With non-compliant engines (such as Stockfish 10, and many USI engines) that fail to respond to the 'isready' this would lead to hanging engine processes when WinBoard finally killed the adapter that was waiting for the 'readyok' that would never come.
I also fixed a synchronization problem that would sometimes lead to starting of a spurious search during loading of a game (where moves could arrive changing the side to move while a preceding 'force' command still resided unexecuted in the command queue).
The downloads with the new UCI2WB are at:
Bare UCI2WB.exe: http://hgm.nubati.net/UCI2WB.zip
WinBoard-AA bundle: http://hgm.nubati.net/WinBoard-AA.zip