Run more than one micropython instance

[pythoncoder]

@pfalcon Regrettable the fact may be, but my code exists. Its development used only my own time and resources. It's essentially complete and I've moved on. I fail to see how its mere existence detracts from the Micropython project or diverts effort from it.

Yet you appear to disapprove when, in an attempt to help others, I point it out. How does my doing this detract from uasyncio? Those who might use my code won't necessarily have the skills, experience or resources to assist in the development of uasyncio. For a user wishing to program the Micropython board using lightweight threads my code, "half baked" or not, offers a solution; currently, to the best of my knowledge, the only solution. Do you really feel I should avoid mentioning it or even delete it from Github? I'm not trying to be contentious here. I'm genuinely struggling to understand your position.

Regarding your suggestion of my participating in the uasyncio effort I'll consider it, but I'd need to spend time improving my competence with the asyncio paradigm to ensure I had the necessary skills to contribute code.

On the eternal topic of the tension between standardisation and diversity in open source I appreciate your concerns; doubtless we could enjoy a lively and interesting debate, but I'm sure you'll agree this isn't the right forum.

[pfalcon]

I'm genuinely struggling to understand your position.

I don't know why you try focus on my perceived disapproval of your project, vs what I tried to clarified explicitly - that it would be nice if we cooperated on one universal solution instead.

to the best of my knowledge, the only solution.

No, uasyncio was intended to run on pyboard, was made to run on pyboard, and with help of others can be debugged and optimized to run there very well. And all that while staying compatible with CPython, so people who know it (and there're plenty of docs, tutorials, etc - it's official Python module after all), can use their skills on pyboard right away. And those who just learn Python, will be learning real Python, not some obscure dialect of. That's the idea (the reality is not so black&white, but...)

Do you really feel I should avoid mentioning it or even delete it from Github?

No, I just felt that you might be interested in uasyncio, and if not, I really wondered why.

you'll agree this isn't the right forum.

Yes, I'm sorry for essentially hijacking this thread. But little could have been added to the original question. I just point out that running concurrent interpreters are not really needed, unless there're multiple CPU cores which can run in parallel. Even then, it might be possible to use instead of threads, independent processing (with separate address spaces), communicating over some IPC mechanism. For anything else, cooperative multitasking should be enough.

Anyway, this issue is tracked as https://github.com/micropython/micropython/issues/595 . Parties who are seriously interested in this issue, can monitor it/discuss implementation issues there.

[tarun2121]

Thanks to all for replying.
I want to run multiple python codes on STM board. Say my task1 is being executed and task2 comes with higher priority. Now I want to put Task1 on pause and let task2 finish its execution and then Task1 will resume from same situation where it was paused. By this way my need is to handle 4 tasks. If running multiple instances of micropython is not a solution then what alternate I should try. Can we add Threading library(as in CPython) by writing some code or from source code of CPython?


-Tarun

[pfalcon]

As above messages suggested, you should try uasyncio: http://forum.micropython.org/viewtopic.php?f=3&t=85

[cloudformdesign]

What are the main challenges in developing a threading module for micro python? I had come to understand it was related to the memory manager / garbage collector, is that true?

[dhylands]

Right.

Each thread needs its own stack (which is just memory).

And there is also the issue of allocating during an ISR (which we currently don't allow).

Ideally (to support multi-threading), we'd want to have one thread be able to allocate while another thread has triggered a GC.

[cloudformdesign]

Why can't you just have an always running thread that just garbage collects when things get suitably bad, and lock allocation during that time?

Threads that would currently "trigger" gc would just have to wait till it is done

[stijn]

Two reasons I can think of: one thread dedicated to just GC is a waste of resources plus it would be sleeping most of the time anyway. Second: locking allocation at arbitrary points in time is likely not wanted at all in anything realtime (unless that locking is guaranteed to require always less than a certain amount of time, but that is hard to accomplish).

[Turbinenreiter]

Why multi-thread on a single core? On that hardware cooperative multitasking makes much more sense -> uasynco.

[cloudformdesign]

My understanding of asyncio is that it is not well suited to operations that are completely distinct. For example, polling a microphone every 10us and polling a temperature sensor every second, while running an algorithm to analyze the microphone data and send it over TCP. These things are much easier to design for with threads.

Not that asyncio can't do it, just that it isn't the best tool for the job.

Feel free to correct me if I'm wrong