This forces the engine to poll the input stream and/or to use non-blocking I/O. (BTW your method will fail if the 003 is not the first character in the input stream.)

I see that a gtp_interrupt() cannot be added as easily to gtp.c (which using blocking IO) as I thought. Or is there any way to check a blocking stream, if the next read would block?

In principle the engine wouldn't be forced to poll the stream. If it doesn't support interrupting it would just eat up any ^C characters before reading the next command. If it does support interrupting, it still could use blocking I/O, (but would have to run it in a separate thread).

^C will always be the first character, since the controlling program can ensure that it does not send ^C in the middle of a command.

TCP/IP allows "out of band data" for this purpose. Telnet uses this feature to deliver the ^C to the terminal-driver (which generates an interrupt)

I was thinking about this, but it does work only with TCP, not with any kind of stream. So there would be different methods of interrupting for local engines (run with exec from the GUI) and network connections.

Strictly speaking, this is not a text-command. It will be hard to implement it in a portable way. Some engines

Why? Transmitting the interrupt signal as a character over the regular GTP stream is the most portable thing I could think of.

may not like it. But maybe we should just standardise (some) of the semantics, and leave the implementation to the engine/gtp-driver

If the engine does not like it, it should ignore it and just eat all ^C characters before reading the next command.

Maybe it would be sufficient if there is a standardized optional GTP command to query the engine, if it supports interrupting, so that the controlling program would use this feature only, if the engine supports it.

- Markus