[Stackless] Issue#24: killing tasklets during thread state cleanup

[Kristján Valur Jónsson]

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.
K

> -----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
> 
> Hi,
> 
> I recently proposed a modification of the behaviour of Stackless Python 2.7.
> For details see http://www.stackless.com/ticket/24.
> 
> Problem
> 
> Upon end of a thread Stackless Python kills every tasklet, that belongs to the
> thread.
> 
> 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
> twice:
> - 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
> once.
> 
> This behaviour is inconsistent and can cause unexpected behaviour. We
> need a way to ensure, that the original tasklet gets deleted without being
> revivified.
> 
> Proposal
> 
> 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.
> 
> Alternatives
> 
> - 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
> ticket.
> 
> Regards
>    Anselm
> 
> --
>   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
> http://www.stackless.com/mailman/listinfo/stackless