Feb 27, 2023

The catch with console input is always that the console input needs to terminate the input, since reading from std::istream is always a blocking call and there's no way to unblock it. Terminating absent a successful read implies thread termination, which is process corrupting. So the capture class launches one thread for the blocking read, and another for posting notification and accepting subscriptions via its own internal strand (just like logger). These are set to high priority, so accelerate actions posted via the console, such as stop. Since the threads are almost entirely idle, this has no material impact on the process. The only downside is that in the case of a self-termination (i.e. the node decides it must stop), the process cannot terminate. It just await console input in order to unblock the input thread. So it posts a line to the console (via logger) to hit <enter> to close. Otherwise the interface is very clean, just construct on std:cin& and subscribe to lines captured from input. It's nice that, at least on win32, a signal such as <ctrl-c> causes both an interrupt and an input event, so there is no need to wait on input. And of course if input terminates (e.g. user types "q" <enter>), then the input can terminate as well. So only on self-termination must it wait. The subscription model allows for input to be written back to the log (explicit and controlled echo). I turn of console echo in construct, as otherwise input text gets interleaved with console output and this is presumably not thread safe.