[Stackless] Problems with removing tasklet.

Christian Tismer tismer at tismer.com
Thu Oct 10 00:08:27 CEST 2002


Gustavo Niemeyer wrote:
>>Actually, although I do fall back on that, but I have also implemented
>>an addition to the stackless module that does the equivalent but
>>much faster (i.e. basically uses the interrupt to directly call
>>stackless.schedule()) Of course the interrupt only will switch when
>>the atomic flag is not set.
> 
> 
> Where's the code? Where's the code? :-)
> 
> 
>>I am finding it pretty stable -- but you definitely do have to know
>>what you're doing to avoid wierdness...
> 
> 
> I've read that about tasklet switching many times. I'd like to
> understand better what kind of problems one can have when switching
> preemptively. I mean, in addition to the well-known problems which
> traditional parallel computing presents. I understand that variables
> returned from the stack can easily break, but could you mention
> something else?

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.
By doing it explicitly, switches will only occour in contexts
where you planned for it. This is much simpler to handle.

Old stackless didn't have this problem, since switching would
never have happened in a nested interpreter situation, unless
a user explicitly demanded it.
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.

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.

some clarity removed now? :-)

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer at tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/


_______________________________________________
Stackless mailing list
Stackless at www.tismer.com
http://www.tismer.com/mailman/listinfo/stackless



More information about the Stackless mailing list