[Stackless] no gil?
rbabiak at gmail.com
Fri Apr 18 06:02:27 CEST 2014
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.
Life, baa I will worry about when it is done!
> On Apr 17, 2014, at 8:20 AM, Kristján Valur Jónsson <kristjan at ccpgames.com> 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.
> Stackless mailing list
> Stackless at stackless.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Stackless