I realize I should answer the signal part. tokio::signal-type code would not work for `bc` signals. `bc` is a special program; most programs are I/O-bound, bu

I realize I should answer the signal part. tokio::signal-type code would not work for `bc` signals. `bc` is a special program; most programs are I/O-bound, but `bc` is both I/O- and CPU-bound. And it's interactive, so it's got to respond to the user as fast as possible. It's quite possible for a user to enter an expression, not realizing how expensive it is to compute (since `bc`'s numbers can be arbitrarily large). In that case, a `SIGINT` should be responded to instantly. Turning signals into an event stream to read would not do that because the signal handler literally has to `longjmp()` out of itself. It won't `longjmp()` out if it's not safe to do so, but it can be safe to do so. And when it is not safe to do so, it will set a flag and return normally. Then the code that wasn't safe to jump around finishes, it will check the flag and jump itself once it is safe. This is what keeps my `bc` responsive even if you have a long-running computation. To see this, compile and run my `bc`, and give it this input: >>> 2^2^32 It will hang because it's calculating a LARGE number. Press Ctrl+C. It will instantly return to the input prompt. I might be wrong that tokio::signal cannot do that, and if so, I apologize. But it doesn't appear so from your description. Also, I have the same sort of code in my new project to turn signals into an event stream in C.