[Stackless] Problems with removing tasklet.

[Christian Tismer]

Gustavo Niemeyer wrote:
>>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
> safe, right?

Yes, physically.
It might break logically, anyway.
For example, you might have code that protects
itself from multithreading by semaphores, but this
doesn't make it microthread-safe, since the thread related
semaphore stuff isn't aware of the existance of microthreads,
which appear to be the same thread all the time.

> 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?

"Local stack mess":
The above is bad enough. C local variables are used like globals
in the context of a Python callback. It happens much more
often than expected.

"Global state mess":
A second issue is what I said above concerning Python code.
It is even more true for C code like Tcl/Tk. Suddenly there
are mcirothreads, but Tcl/Tk doesn't know about that, it still
thinks there is just one thread, and you might be able to
jump out of a Tcl callback which doesn't expect this, and
continue a different Tcl callback which is dependant from the
same status variables.

...

>>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?

Yes.

...

> 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?

This is hard to answer.
For some reason like easy thread pickling, I'm all for it.
But getting rid of this difficult code was the major
reason why I started the new stackless. I don't want to
do this again, to this extent. That's why I'm all against it.

Maybe there exists a minimal solution which involves
as few as possible changes to the core interpreter and
still gives switching capabilities without the stack
tricks. Would be of benefit, since this creates program
state that can be pickled.

I fear it will not happen. If anybody wants to try to
re-do the old Stackless tricks: It took me *months*
to get it running, and it takes *weeks* to move from
one Python version to the other.

Not with what I have today: The port 2.1->2.2 was 2 hours.

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