[Stackless] no gil?

Richard Tew richard.m.tew at gmail.com
Fri Apr 18 08:05:49 CEST 2014


Regarding moving tasklets between threads, it should be possible to
implement this yourself to some degree by pickling and unpickling and
writing a framework to manage it.

IMO the best thing about Stackless is the low-level primitives  and
support, and the ability to implement these sorts of things yourself.

On 4/18/14, Adam Turk <adamlturk at gmail.com> wrote:
> 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
>>
>



More information about the Stackless mailing list