[Stackless] a stackless crash
tismer at stackless.com
Wed Nov 7 02:42:32 CET 2007
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.
> 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.
>>> 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
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/
More information about the Stackless