On Wed, Jun 23, 2010 at 4:34 AM, Andrew Francis <[email protected]> wrote: > 1) Relationship between scheduler and OS threads. > > In Stackless Python, from reading past posts I believe you can have > OS threads as well and the tasklets in different threads still can > communicate via channels (in the code there is a tstate and interthread > variable). In short, the scheduler is a singleton. There is a 1 to N > relationship between schedulers and OS threads although the > reality is typically one uses only one OS thread? More threads could > be used - but it difficult to take advantage of them.
http://www.disinterest.org/resource/stackless/2.6-docs-html/library/stackless/threads.html#a-scheduler-per-thread > Again, I think this issue was brought up in the mailing list: the GIL > and performance issues notwithstanding, what is stopping a future > Stackless Python implementation from moving a tasklet making a potentially > blocking call to a new OS thread? As Christian has stated in the past, this is already possible unless it isn't. Where it isn't, is where there are C stack frames involved. These are of course tied to the old thread and in turn tie the tasklet to it. > 2) Fairness > > I sort of allude to fairness in "Adventures." However Krisjan goes into great > lengths about fairness in the 2009 talk "Stackless Python in EVE #2" there is > much discussion about fairness. This is opposed to a certain amount of > non-determinism in Newsqueak and Go. Could this be a distinguishing > philosophical difference in the languages? No idea. Cheers, Richard. _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
