peterhinch / micropython-mqtt

A 'resilient' asynchronous MQTT driver. Recovers from WiFi and broker outages.
MIT License
549 stars 116 forks source link

Clarification of why 'asyncio.new_event_loop()' invoked at the end of a script, say clean.py? #91

Closed Jibun-no-Kage closed 1 year ago

Jibun-no-Kage commented 1 year ago

Clarification of why 'asyncio.new_event_loop()' invoked at the end of a script, say clean.py? Not sure I understand why this is done when the script is effectively ending, as in the case of clean.py for example.

peterhinch commented 1 year ago

See tutorial section 7.2.

Jibun-no-Kage commented 1 year ago

Really interesting, I was looking at python3 asyncio documentation and did not see an explicit reference. Thanks for the pointer I realize now I have a bit of blind spot... MicroPython is (just that) different than traditional python.

peterhinch commented 1 year ago

CPython also has asyncio.new_event_loop. A typical PC application does not need the method because, on termination, the Python interpreter returns you to the OS and all state is lost. As I understand it the method has the same purpose as in MP: to discard asyncio context.

The problem of retained context occurs on embedded platforms in test situations where, at the REPL, you want to run a test script repeatedly.

Jibun-no-Kage commented 1 year ago

Right, you raised the point I was thinking as I read you above comment, a hard or warm reset (on a Microcontroller) would hide the issue of less than graceful clean up. I have extensive history with various virtual environments, VMware, Hyper-V, KVM, Xen, LXC, docker, etc., and the lack of resource recovery or clean up is a big deal for such of course. I was going to ask initially why a gather was not done, to allow cleanup, but that has the potential of never ending under the right conditions, which is an entire issue unto its-self as well. As always, thanks for the insight, I am learning a lot fast about MP.