So, following our discussion here, http://www.stackless.com/ticket/9 I'd like to add the the new behavior of tasklet.atomic, to inhibit thread switching, is really only possible in our GIL based cpython world. But I actually view this as a benefit. Given that the cpython implementation, the only current stackless implemantaion, is GIL based, this makes ensuring local critical sections a breeze.
In fact, so much so, that I would recommend this to the CPython crowd. There is every so often the discussion here and there whether this or that operation is 'atomic" or not. Can list.appen() be considere atomic? What about ordered dictionary inserts? Etc. etc. People discuss this back and forth and certain guarantees are made and not made. I'd argue that the stackless.atomic flag should be moved to be sys.atomic, and be per thread. It should mean that there will be no involountary gil based thread switches while it is in effect. It would solve a number of synchronization problems with thread based python. Unfortunately, I see the counter arguments already: 1) It will not be truly atomic when there are blocking calls that truly do yield the GIL 2) It is not portable to the versions of python that don't have a GIL. The latter is the more significant, and the reason I'm not currently advocating this to Guido et al, but as I sated before, stackless is purely a cPython, GIL based, thing, and likely to remain so until further notice :) K
_______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
