The way I understand it the global interpreter lock was added to Python to support threads on single-core processors in the early 90s. At the time 486 processors were popular and the Pentium was just getting started.Not entirely as MicroPython is generally version 3.4 compatible with some adoption of later version features but, yes, having it run on more constrained hardware does mean things are quite different under the hood, and it wasn't designed to support everything CPython does, nor do things in exactly the same way.CPython is admittedly off topic for MicroPython which is different and has its own challenges.
That does mean there can be more challenges in adding something CPython supports because it has to fit with MicroPython design choices or those choices have to be modified or updated. And that can be difficult to do as we have seen with threading.
MicroPython language is a reimplementation of the CPython language and it's mostly the availability and functionality of modules which differ. But sometimes, as with threading, its success is reliant on things deep within the language support implementation.
In the late 90s the Pentium Pro allowed 4 socket configurations while the SGI Origin 2000 came in exotic NUMA configurations with as many cores as today's x86 processors. As dual socket servers became common, Python was no longer only for teaching; however, it remained focused in areas where parallel and concurrency were unimportant and so kept the global interpreter lock.
MicroPython is newer and multi-core processors were common when threading was added, even on MCUs. As a result MicroPython threads attempt to run concurrently on multiple cores.
Somehow it's still difficult.
Statistics: Posted by ejolson — Wed Nov 27, 2024 4:15 pm