Run more than one micropython instance

[tarun2121]

Hello all
I need to run more than one(say 4) micropython on my STM32F4 board. Is it possible? Is there any idea regarding the same?

[dhylands]

What are you trying to accomplish by running multiple instances?

This is not currently possible (as micropython assumes that it owns the entire processor).

[tarun2121]

Thanks for replying Dave
I actually want to execute more than one Python codes at same time(by switching between them, feel of multithreading). Can I do it?




-Tarun

[shell]

Then, why not use threads?

[pfalcon]

Well, having multiple interpreter instances is how many (most?) interpreted languages implement multithreading support - each thread runs its own interpreter. Nope, we don't have support for that. I asked @dpgeorge how he'd feel if each function took extra parameter - interpreter instance pointers, don't remember that he'd even reply . (Well, we could use TLS of course to simplify it on user side, but that would complicate portability. And multiple instance support still adds overhead.)

[pythoncoder]

The cPython library has various mechanisms for implementing concurrency without explicitly running multiple Python instances. These vary in the degree to which they bypass the Global Interpreter Lock. I don't think any of the truly concurrent approaches have been ported to Micropython. In Micropython one approach is to implement coroutines using Python's yield and yield from keywords. Another is to use the asyncio library but I'm not sure if the port to the Micropython board is yet proven.

Here is my effort using generators/coroutines targeted specifically at the board. https://github.com/peterhinch/Micropython-scheduler.git

Regards, Pete

[pfalcon]

The cPython library has various mechanisms for implementing concurrency without explicitly running multiple Python instances.

Yes, CPython is one well-known exception of an approach "one thread - one interpreter instance", and everyone knows how they do that - by employing the dreaded

Global Interpreter Lock.

Here is my effort using generators/coroutines targeted specifically at the board. https://github.com/peterhinch/Micropython-scheduler.git

pythoncoder, I suggest you instead of trying to go with your adhoc solution (and leading others to it), rather participate in a community effort to develop a module which is (as much as possible) compatible with standard Python approach of doing cooperative multitasking - asyncio. More info is here: http://forum.micropython.org/viewtopic.php?f=3&t=85 . YMMV of course.

[Damien]

It will be some time (maybe a long time) before uPy supports multithreading on the pyboard.

What exactly do you want to do with multithreading? There are already a few ways you can do similar things, like using hardware interrupts to pre-empt some code.

And as @pfalcon says, there is the uasyncio module which is intended to provide a comprehensive solution to running things in "parallel". But it is not yet fully working.

[pythoncoder]

@pfalcon I'm sorry you don't like my approach. I struggle to see why I should avoid referring to code which some may find useful: I was of the view that the spirit of open source includes offering a variety of solutions. I would respectfully suggest that my code does have some merit. It actually works on the Micropython board. It uses a paradigm which, while admittedly old, is consequently familiar to many Python programmers. It has specific support for the hardware with example applications. I've made considerable efforts to document it. However I've no desire to cause contention and if it emerges that your opinion is the consensus view I'll refrain from referring to it again.

Finally a word of reassurance to other participants. I've been around far too long to engage in flame wars but I'll listen to any views expressed.

[pfalcon]

@pfalcon I'm sorry you don't like my approach.

Yeah, I probably missed "would" somewhere typing too fast, sorry. And it's not that I don't like your approach, it's that if everyone will dig his/her own approach, we won't get too far as a community. Probably we'll skid in place until juice runs out, like previous approaches of small Python implementation did. And yeah, I don't like that. Your documentation, examples are great, and that's exactly what I mean - if you could join uasyncio effort, that would be great bump to it. And it's not the first time where our two solutions meet in one topic, seemingly going in parallel to each other (or may I say ignoring each other?). So yep, I kinda tried - perhaps somewhat impatiently - to get some resolution of this situation. Well, at least now, we know that there're 2 half-baked async frameworks around not because their authors don't know about each other's work, but due to some other reasons.