fadushin / esp8266

This repository contains source code for the ESP8266.
BSD 2-Clause "Simplified" License
73 stars 22 forks source link

server.run() is blocking #17

Closed gampam2000 closed 6 years ago

gampam2000 commented 6 years ago

Hi, great work, I tried your examples and they work but if I call server.run() the esp8266 is blocked until I press CTRL-C. As far as I understood the description it should only be blocking while serving request?

I run MicroPython v1.9.3-8-g63826ac5c on 2017-11-01; with mpy-cross compiled uhttpd as .mpy

Any Ideas?

fadushin commented 6 years ago

Yes, that is indeed the intention. run is a blocking call, as it is now fully integrated with the uasyncio library. However, you can still use uhttpd with "concurrent" code. See, for example, asyncio_uhttpd. I am working on some tutorial work now, that should make this more clear. It is complicated, but honestly it is a micro python "best practice"

gampam2000 commented 6 years ago

Ok, thanks for the answer, in the meantime I used a machine.Timer for concurrent tasks, which also worked fine. I also tried your example, it works similar to the timer. Are there pro/cons for using timers or the asyncio event loop?

Even when the run is blocking, is there an option to get the repl prompt back while the uhttps server runs? This would be great for debugging purposes?

fadushin commented 6 years ago

Using timers is risky, because you have to be very careful about not allocating memory in your interrupt handler. As a consequence, you need to share data between your interruptions handlers and your main loop, which can also be tricky. I am not sure what guarantees you have around mutual exclusion on memory segments, in cases like that. Using asyncio gives you better guarantees about re-entrancy, if I understand how Paul has done it, because none of your code is running in parallel.

Unfortunately, there is no way to get the read-eval-print loop back. You might look at an older version of uhttpd, such as d6d97dfd8526eb0b32470dd43ad838195b83f95d, but there are likely to be bugs in that code that have since been fixed. I usually find that I can debug fairly effectively with log or print statements, or by stopping the web server, inspecting state, and then resuming via usasuncio.get_event_loop().run_forever(). That should bring the web server back up.

gampam2000 commented 6 years ago

Thanks for the tip with uasyncio.get_event_loop().run_forever() this solved it. Because if I started the server after stopping it with server.run(), I always got a memory error. Also thanks for suggestion to run other tasks also in the uasyncio event loop, this also works fine.