[Stackless] no gil?

Adam Turk 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
> 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
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stackless.com/pipermail/stackless/attachments/20140417/5f0f39f4/attachment-0001.html>


More information about the Stackless mailing list