Hi Richard:
>http://www.disinterest.org/resource/stackless/2.6-docs-html/library
>/stackless/threads.html#a-scheduler-per-thread
Thanks a lot!
AF> Again, I think this issue was brought up in the mailing list: the GIL
AF> and performance issues notwithstanding, what is stopping a future
AF> Stackless Python implementation from moving a tasklet making a
AF>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.
Fair enough. Realistically wouldn't the tasklets that would potentially
block, such as something that would make a syscall() under the hood,
have a C stack? Hence making this somewhat useless in Stackless?
Cheers,
Andrew
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
