Add content for handling input from keyboard on POSIX compatible plat…

…forms and abnormal program termination via Ctrl+C.

Signed-off-by: Michael Orlov <morlovmr@gmail.com>

docs/design/keyboard_handler.md

@@ -83,6 +83,27 @@ function keys represented as two integer values. Note: for some key combinations
 value could contain '\0' value representing null terminator in regular strings. 
 i.e it is not possible to treat such sequence of bytes as regular strings.
 
+###Specific of handling input from keyboard on POSIX compatible platforms
+POSIX systems support two basic modes of input: canonical and noncanonical. In canonical input 
+processing mode, terminal input is processed in lines terminated by newline '\n', EOF, or 
+EOL characters. No input can be read until an entire line has been typed by the user. Most 
+programs use canonical input mode, because this gives the user a way to edit input line by line 
+and this is what many of users accustom to see when typing commands in terminal window. \
+However to be able to handle single key press, terminal input need to be switched to the 
+noncanonical mode. By design keyboard handler will switch current terminal session to the 
+noncanonical mode during construction and return it to the canonical mode in destructor.
+
+##Handling abnormal program termination via Ctrl+C
+By design keyboard handler not providing ability to transfer `Ctrl+C` key press event to its 
+clients via callbacks. It could be considered as current design limitation.  
+On POSIX compatible platforms when user pressing `Ctrl+C` OS generates specific `SIGINT` signal 
+and if this signal became unhandled current process will be terminated. \
+On POSIX compatible platforms keyboard handler will register it's own signal handler for the 
+`SIGINT` to be able to return terminal input in canonical mode after abnormal program termination 
+via pressing `Ctrl+C`. This signal handling could overlap with registered specific `SIGINT` 
+handler on upper level or inside keyboard handler's clients. It could cause side effects and 
+considering as current design and implementation limitations. 
+
 ## Handling cases when client's code subscribed to the key press event got destructed before keyboard handler.
 There are two options to properly handle this case:
 1. Keep callback handle returning from `KeyboardHandler::add_key_press_callback(..)` and use it