[Stackless] a stackless crash

[Christian Tismer]

Kristján Valur Jónsson wrote:
> 
>> -----Original Message-----
>> From: Christian Tismer [mailto:tismer at stackless.com]
>> This is not true, see the start of channelobject.c .
>> The channel gets temporarily resurrected, and it is
>> anyway visible through its members, since it is the
>> head of the taskets that it contains.
>> Therefore, it is possible to create new references,
>> and the beast stays alive.
>> Maybe this was a bad hack in order to save a pointer,
>> but it is so right now.

Kristján, would you please wrap your email into short
lines? I always have to do this for you since years :-)

> Ok, but do we really need to resurrect it?  If it is only
> accessible throug the prev- and next pointers, then
> it should be simple to just unlink the tasklets before
> killing them.  Then the channel is gone.

Ok.

> Anyway, we are attempting to kill the tasklet at the end
> of execution.  If what you are saying is correct, then
> it might aswell insert itself into the channel at this
> point too.  I don't see that postponing the tasklet kill
> until the end of execution avoids the problem.

right. I just thought that since I cannot prevend this
at all, it does not matter when to try killing them, since it
is hard, anyway. When we actually try it is a matter of taste,
and I don't care if you prefer it to be earlier.
Maybe an improvement, yes.

> I think the solution is to make it impossible to do
> that, by making the channel inaccessible to python code.

Good.

>>> Killing the tasklets at the time we are destroying the channel
>>  > seems like a much better place to do it and may even make the
>>  > late "kill tasklets with cstacks" code unnecessary.
>>
>> a) better place than what?
>>     You cannot really kill a tasklet immediately. Maybe it would
>>     be nicer to try to kill it earlier, yes, considerable,
>>     but no guarantee.

> Better than waiting until program exit.  So, why can't we
> wake up the tasklet immediately with an
> exception?

Sure we can.

>> b) Why should this late code become unnecessary. Maybe I should
>>     write up a (bad) design paper?
>>     There always can be any number of taskets floating around,
>>     which are not blocked, just remove()d. They need to be cleaned
>>     up in the end.
> 
> Ok, but where are they linked in?  Do they have valid prev and
> next pointers?  Remember, the crash comes as a
> result of the unlinked tasklets having a null prev and next
> pointer (since they were unlinked from the channel)

They are linked via their cstack instances, just for clean-up.

> Maybe this is all a non-issue if we just fix the issue with unlinked tasklets...

Maybe I just forgot to handle corner-cases, there, yes.

> Okay, it turns out we don't need the channel to see this bug!!!!!
> See the two attached files for an even simpler way.  A tasklet with a cstack that does a remove!
> No messy channel to muddy the waters.

Good! So after all, this is not really channel related, just the
remove code is not really developed regarding cstacks!

thanks & cheers - chris
-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
tismerysoft GmbH             :     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 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
       whom do you want to sponsor today?   http://www.stackless.com/