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 <[email protected]> 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 < > [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
