[Stackless] Issue#24: killing tasklets during thread state cleanup
tismer at stackless.com
Tue Jun 11 14:14:40 CEST 2013
Yeah, I just left the ticked, went to the list, and came back ;-)
I'm pretty curious about "unbind" and what it is...
cheers - chris
On 11.06.13 11:18, Kristján Valur Jónsson wrote:
> Just thought I'd let you know that due to lack of response, this discussion Is continuing in the ticket.
> Anselm made the interesting suggestion to "unbind" a tasklet. I like that thought.
>> -----Original Message-----
>> From: stackless-bounces at stackless.com [mailto:stackless-
>> bounces at stackless.com] On Behalf Of Anselm Kruis
>> Sent: 4. júní 2013 12:16
>> To: The Stackless Python Mailing List
>> Subject: [Stackless] Issue#24: killing tasklets during thread state cleanup
>> I recently proposed a modification of the behaviour of Stackless Python 2.7.
>> For details see http://www.stackless.com/ticket/24.
>> Upon end of a thread Stackless Python kills every tasklet, that belongs to the
>> This behaviour is fine except for one case: if you pickle a tasklet and later
>> unpickle and continue the tasklet, pending finally blocks will be executed
>> - in the original tasklet during the processing of the TaskletExit exception
>> - in the unpickled tasklet during normal processing.
>> If the tasklet is deleted prior to the end of the thread, finally blocks run only
>> This behaviour is inconsistent and can cause unexpected behaviour. We
>> need a way to ensure, that the original tasklet gets deleted without being
>> I propose to exempt a tasklet from being killed, if the tasklet is restorable
>> and not scheduled (stackless.schedule_remove() or
>> tasklet.remove() was called). Such a tasklet would silently get deleted, if its
>> reference count reaches zero.
>> - One could add a flag to a tasklet that marks the tasklet as being serialised
>> and skip killing based on the flag.
>> - Modify tasklet.bind(callable) to allow rebinding an alive tasklet.
>> Then one could use tasklet.bind(lambda :None) to effectively disable killing.
>> Open questions
>> Are there any known use cases, that depend on the current behaviour? Are
>> there better alternatives?
>> I'd like to discuss the general way to to solve this issue on the mailing list.
>> Once there is a consensus, we can sort out implementation details in the
>> Dipl. Phys. Anselm Kruis science + computing ag
>> Senior Solution Architect Ingolstädter Str. 22
>> email A.Kruis at science-computing.de 80807 München, Germany
>> phone +49 89 356386 874 fax 737 www.science-computing.de
>> Vorstandsvorsitzender/Chairman of the board of management:
>> Gerd-Lothar Leonhart
>> Vorstand/Board of Management:
>> Dr. Bernd Finkbeiner, Michael Heinrichs, Dr. Arno Steitz, Dr. Ingrid Zech
>> Vorsitzender des Aufsichtsrats/ Chairman of the Supervisory Board:
>> Philippe Miltin
>> Sitz/Registered Office: Tuebingen
>> Registergericht/Registration Court: Stuttgart Registernummer/Commercial
>> Register No.: HRB 382196
>> Stackless mailing list
>> Stackless at stackless.com
> Stackless mailing list
> Stackless at stackless.com
Christian Tismer :^) <mailto:tismer at stackless.com>
Software Consulting : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/
14482 Potsdam : PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776 fax +49 (30) 700143-0023
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