Reading GUI Input During Search

[hgm]

I have a hard time imagining why you would have output 'scattered all through the engine'. The only places where my engine outputs something (apart from debug output, for which it is essential anyway that it is in absolute sync with the search thread) is in the move loop of the root search (for printing PVs), print the chosen move after the search returns, and in the protocol interpreter (for replying to commands that need a reply, of which there are preciously few). For the latter class there is no need to test the protocol you are using, as the input command already identified that. E.g. to reply to isready you can just print readyok, and in reply to ping N print pong N, without any need to know to which protocol these commands belong.

It also seems to me that you could keep the protocol test entirely out of the engine, by calling a generic output routine that does the test itself. I.e. just have routines PrintPV and PrintBestMove.

[mvanthoor]

I have a hard time imagining why you would have output 'scattered all through the engine'.

I sure can. Seen enough engines that output stuff in the main function, in the search function, even in the input thread (if there is any) when they detect invalid input; and lots of other places (basically wherever the author decides that something needs to be printed).

It also seems to me that you could keep the protocol test entirely out of the engine, by calling a generic output routine that does the test itself. I.e. just have routines PrintPV and PrintBestMove.

*shrug* In my case I just load a communication module that implements a protocol, be it UCI or XBoard or whatever, and it takes care of any input and output. The engine itself doesn't know anything about it except for the handler it should use. It has one handler per protocol module. It basically functions a bit like a webserver. You can load a PHP module or a Python module and tell the webserver to use the Python one for .py files, and the PHP one for .php files. My engine is similar. Therefore I can extend the engine with any protocol I like by just writing the protocol module and a handler for it, without touching the rest of the engine.

I could probably have done so without an output thread, but as said, then the coding style and workings would be different from input thread and I didn't want that.

[jdart]

I wonder why the anti-pattern of polling commands inside search is still prevalent
just move your search logic into a separate thread and then you can have keep your blocking read in the main thread,
this is also more flexible - or you can keep on copy-pasting from VICE, your call

I used to use input polling during search, then I went to a separate thread, then I went back to input polling, because there is no convenient blocking read but with timeout (like select) on the Windows platform, and so if I did a blocking read in the input thread, the program was failing to shut down cleanly because it wasn't killing the input thread. And I didn't want a non-blocking call in the input thread, because then the thread spins consuming resources with no input.

see https://github.com/jdart1/arasan-chess/ ... /input.cpp for the platform-dependent input code.

[mar]

I used to use input polling during search, then I went to a separate thread, then I went back to input polling, because there is no convenient blocking read but with timeout (like select) on the Windows platform, and so if I did a blocking read in the input thread, the program was failing to shut down cleanly because it wasn't killing the input thread. And I didn't want a non-blocking call in the input thread, because then the thread spins consuming resources with no input.

see https://github.com/jdart1/arasan-chess/ ... /input.cpp for the platform-dependent input code.

I don't understand why you need a blocking read with a timeout (also no need for input thread),
either way a clean exit is when you parse a quit command from the GUI, so I don't see any problem here
I simply do input processing in the main thread via a blocking read, no need for platform-specific stuff here