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 < [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
