[Stackless] no gil?
adamlturk at gmail.com
Fri Apr 18 05:03:01 CEST 2014
I have often dreamt of a Python without the GIL. There are many positives,
as you stated and more. But there are also many negatives, as with any
multithreaded model in C/C++. I often embed (extend, in truth) Python
within my projects. The single-threaded model there works to my advantage
as I have only one "scripting" thread within the larger engine. I know in
some cases, like what I understand about Carbon and also the SSL connection
case, threads are created at the OS level to handle blocking operations so
that Stackless isn't locked waiting for a return, which is somewhat
backwards. If there was no GIL, and Stackless could run tasklets across
threads these cases could be handled in a far more elegant way.
A few things I would like to see:
+ The ability to put a tasklet on a specific thread. (Perhaps some form of
tasklet "weight" - heavy tasklets on a certain thread, or their own thread)
+ Some form of tasklet thread pool that can be strictly controlled
On Thu, Apr 17, 2014 at 9: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
> 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