idf_monitor: make Ctrl-] work when running on WSL (v3) #1324
Conversation
Because the TIOCSTI termios ioctl is not supported on WSL (bash on windows) at this time, another way for avoiding (or unblocking) a blocking read on stdin is needed. Also, setting a timeout using termios.c_cc[VMIN] = 0 with termios.c_cc[VTIME] = 1 does not currently work for WSL. A first approach to mimic the Windows kludge based on kbhit() by using ioctl(TIOCINQ) for peeking at the input queue before calling read() basically worked but failed badly for fast multi character input like escape sequences sent back by the terminal. This can be easily reproduced using the console example (examples/system/console). The root cause was identified to be the buffering involved reading and decoding stdin in python. The second approach used pthread_kill() via ctypes (python 2) to unblock getkey() in ConsoleReader which seemed to be working well. However, even in this case stdin must have been re-opened without buffering. Otherwise, the read() may be restarted internally after seeing EINTR. Additionally, the solution felt at least a bit unclean. After having identified the importance of making stdin unbuffered, it became clear that in this case select() (or other I/O completion methods) should also work correctly. Therefore, the current solution was implemented, which looks a lot cleaner. It should also work on other POSIX systems (e.g., plain Linux), but this has not been tested, so far. The change has been tested successfully on WSL with the console example, escape sequences (UP, DOWN keys), Ctrl-] to leave the monitor and Ctrl-T/Ctrl-A for re-flashing.
|
Now this is the third try to work-around missing TIOCSTI with WSL, as promised.
|
|
JFTR: this change has at least one potential issue with varying length or multibyte per character input (example: UTF-8). If you manage to enter an incomplete UTF-8 sequence, the getkey() might still block when low-level read()s will be called until the sequence will be complete. Not sure if this can really happen. |
|
This pull request is obsolete. TIOCSTI has been implemented in Bash on Windows 10 v1809 (see https://docs.microsoft.com/en-us/windows/wsl/release-notes). Ctrl-] just works on recent Windows 10. |
Because the TIOCSTI termios ioctl is not supported on WSL (bash on
windows) at this time, another way for avoiding (or unblocking) a
blocking read on stdin is needed. Also, setting a timeout using
termios.c_cc[VMIN] = 0 with termios.c_cc[VTIME] = 1 does not currently
work for WSL.
A first approach to mimic the Windows kludge based on kbhit() by using
ioctl(TIOCINQ) for peeking at the input queue before calling read()
basically worked but failed badly for fast multi character input like
escape sequences sent back by the terminal. This can be easily
reproduced using the console example (examples/system/console). The root
cause was identified to be the buffering involved reading and decoding
stdin in python.
The second approach used pthread_kill() via ctypes (python 2) to unblock
getkey() in ConsoleReader which seemed to be working well. However,
even in this case stdin must have been re-opened without buffering.
Otherwise, the read() may be restarted internally after seeing EINTR.
Additionally, the solution felt at least a bit unclean.
After having identified the importance of making stdin unbuffered, it
became clear that in this case select() (or other I/O completion
methods) should also work correctly. Therefore, the current solution was
implemented, which looks a lot cleaner. It should also work on other
POSIX systems (e.g., plain Linux), but this has not been tested, so far.
The change has been tested successfully on WSL with the console example,
escape sequences (UP, DOWN keys), Ctrl-] to leave the monitor and
Ctrl-T/Ctrl-A for re-flashing.