Input system design

Requirements:

• After receiving an input that causes Cursive::quit(), we should not consume any more input.
  • This means before consuming any input, we should make sure the previous input did not stop the event loop.
• Support callback pre-emption: Cursive must be able to react to callbacks sent from other threads while still waiting for input.
  • For blocking input, this means the hanging input has to be running in parallel with the output reacting to callbacks. This means the backend must be somewhat thread-safe.
• Batch input processing: Cursive must be able to process multiple pending events without re-drawing the screen.
  • Combined with the first requirement, this means each input from the batch must be processed before the next one can be consumed.

A solution to satisfy that is composed of 2 channels:

• Input Requests, from Cursive to the backend, notify the backend that it's safe to consume an input.
• Event channel, from the backend to cursive, transmits the event as they arrive.