MicroPython Forum (Archive)

Hi!

I always write my code in this way: doing everything from timers.
I mean my main.py is launched at boot initializes everything it has to, launches a few timers that will do periodic tasks (e.g start the pump to water the plants) and then terminates.
I find very convenient to do so because I do not have a program running continuously in a loop and therefore I can communicate with the system thru webrepl.
I communicate with the system and at the same time the timers will launch the tasks they have to. It works well even with timers doing tasks very often (e.g every seconds).
So it’s a king of multitasking...
Is there anything wrong with that?

Thks
--
Jmp0

Depends. How are your modules communicating with each other? Are you using some kind of synchronization object, or just passing around Python objects?

In general, most Python modules haven't been vetted for thread safety, so running in this kind of multi-threaded environment is a bit hazardous. The few I know of that have been vetted aren't safe. Between the GIL and the interpreter forcing threads into a sort of cooperative multi-tasking, the cPython is safer than I'd assume.

@mwm I agree - that kind of coding needs a lot of care. The lack of thread-safety can be addressed by using mutexes and by disabling interrupts in critical sections but there is plenty of scope for rarely occurring, hard to locate, bugs.

@JumpZero I recommend using cooperative multi-tasking unless there is an inescapable reason for needing a pre-emptive model. This paradigm requires you to determine the points in the code where other tasks can run and hence greatly reduces the potential for nasty bugs. See the uasyncio module.

Thanks for your advices, it's helpful.
I'll consider that and be careful.
--
Jmp0