-
Notifications
You must be signed in to change notification settings - Fork 136
Issue with KeyboardInterrupt and generally STDIN #166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Interesting. The 20ms delays existed to support a project (mqtt-bridge) that has been retired. With a USB connection Hopefully someone with more knowledge will advise. |
Do you have a view on the necessary size of this delay for WebRepl to work? It might be worth testing 10ms and 5ms - I have no objection to reverting to 20ms so long as the value provides is a reasonable safety margin. Removing the 20ms delay did not affect behaviour or performance. |
It looks like it is enough to make a 1ms delay. I've also verified the ability to read other, then CTRL-C inputs from stdin, using the following task:
where the stdin reader is defined that way:
Putting any non-zero time sleep allows you to type anything (although characters are not written back on the console) followed by enter, and "ECHO: anything" is displayed. |
Thanks for testing. I will push an update with a 5ms sleep which will fix your problem without any adverse effects ( It does seem as if you've uncovered an issue with [EDIT] |
During the development, it is nice to have an option to have control over starting and stopping the code. For this, I'm using the webrepl that at least allows me to issue
exec(open('my_main.py').read())
and press CRTL-C to stop it. At least, because usingselect.poll()
I can also send something into the running code from the STDIN.The
connect()
mqtt_as call makes an issue with STDIN. Let's consider the following example code that is started usingexec(open(...).read())
:I expect, that after CTRL-C key press, an "interrupt" would appear on the output and program finish. Unfortunately, it doesn't happen - there is no reaction and only a hard reset is available.
After some digging I've found that the problem is with the
async def _handle_msg(self)
method:(lines 844-853 of
mqtt_as/__init__.py
). Making the non-zero sleep_ms makes things work as expected. Tested on ESP32-S3 and ESP32-C3.I'm not sure why zero sleep prevents handling STDIN. I have some theorems in my mind, but I don't feel strong enough in async world to share with them. If anyone has a good understanding of the cause, please let me know.
It looks like the small delay (20ms) was replaced with zero last year. The potential solution is to make the delay configurable with some default value (like zero, what is at this moment).
Please, express your thoughts.
The text was updated successfully, but these errors were encountered: