[Stackless] Problems with removing tasklet.
niemeyer at conectiva.com
Thu Oct 10 16:44:40 CEST 2002
> When running preemptively, you cannot predict when your code
> is switched. You introduce similar problems as threading
> creates for you.
> For code which you know, you can use the atomic stuff to
> lock certain areas of code. But you don't know which extension
> modules calls back into what Python code and if that can stand
> switching at all.
Python code should always stand switching, *if* it is thread
The problems of letting extensions callback Python code is because
the interpreter (stackless) could switch context, and the calling
code could be using the unadvised programming technique of using
variables returned in the stack. Is there anything else you know
about right now?
(I've just asked the same question to Jeff. It could be better
to wait for his/your answer to check if they don't overlap)
> By doing it explicitly, switches will only occour in contexts
> where you planned for it. This is much simpler to handle.
I belive so..
> Old stackless didn't have this problem, since switching would
> never have happened in a nested interpreter situation, unless
> a user explicitly demanded it.
By "nested interpreter", you mean a situation like
interpreter -> extension -> interpreter, right?
> It was also easy to detect recursions, since the normal
> interpreter mode of old Stackless did not use recursion,
> which meant that *every* recursive call (due to code which
> had not been converted to stackless, or due to extension
> modules) simply should block scheduling.
> New stackless allows switching everywhere, although there
> are interpreter recursions all the time.
> In contrast to the old one, it is no longer trivial to
> determine when to block switching or not, since the old,
> non-recursive behavior is gone, recursions are there
> all the time.
Btw, is there any reason why you'd like to see the old
implementation of stackless reimplemented in the future?
If so, would you think about this (perhaps as a side
project) if there was enough support from the community?
> So, which I got an effective locking mechanism for free
> in old Stackless, I'm now having a hard time to think
> out how to implement this, again.
> But unless I do so, giving a free scheduling mechanism
> to the average user will create lots of complaints
> about breakage for me, and that's what I must prevend.
Fully agreed.. :-)
> some clarity removed now? :-)
All of it.. ;-) Thanks for taking the time to explain this!! I hope I'm
not asking trivial questions, and this thread may be used as a later
[ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]
More information about the Stackless