A GILless python would be an awesome thing. One thing that could be used would be the hardware atomic operations to be able to replace a the stackless lockes.
Is the idea to head to a more GO like interface where the number of hardware threads are managed below the level of the application programmer like in GO? You just spawn a tasklet and the scheduler runns it on the hardware thread that has the most room? I am intreged by what they are sugesting, pass on more as you learn it. Robert Babiak Life, baa I will worry about when it is done! > On Apr 17, 2014, at 8:20 AM, Kristján Valur Jónsson <[email protected]> > wrote: > > Hi there. > At PyCon I was approached by a core developer of CPython who asked me this: > If we had a hypothetical GIL-less CPython, would stackless (tasklets or > co-routines) still be a useful constructs or would real threads be sufficient? > > The question is serious and it is possible that a re-architecture of CPython > will take place. This would involve breaking API compatibility in some ways. > The question would be, if it would make sense for such a hypothetical Python > to be fully non-recursive in its execution form, i.e. “stackless”. The way > CPython uses the c-stack to mirror recursion on the Python stack is very > convenient for the C API. > > So anyway, I couldn’t answer that question right away and had to think it > over. Here are some of my thoughts so far: > 1) Scalability. The reason that libraries like “gevent” exist, to > provide a thread-like execution environment for concurrency. You don’t get > added parallelism with gevent over regular threads but you get a program that > scales better because OS threads are expensive. > 2) Picklability: In order to pickle (and restore) a python execution > frame it must not be from a recursive invocation > 3) Co-operative scheduling: To be able to run multiple execution > contexts without pre-emptive switching is a huge win. If your problem is > such that you are IO bound anyway and cpu doesn”t matter much then this can > be a very attractive programming model. > > Any other thoughts? How would applications of stackless python be different > if there were no GIL, i.e. threads could run in parallel (but tasklets were > co-operatively scheduled in each thread as before)? For one thing, I know > that many synchronization privmitives currently written using channels would > need re-writing. They currently rely on tasklet.atomic for atomicitiy which > also prevents thread switching (by preventing the thread from releasing the > GIL). If there were no GIL, we would need to use additional locking if we > wanted our stackless locking primitives (e.g. stacklesslib.locks) to work > between tasklets of different threads. > > Food for thought, anyway. > > K > _______________________________________________ > Stackless mailing list > [email protected] > http://www.stackless.com/mailman/listinfo/stackless
_______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
