[PyPy-issue] [issue693] Documentation needed: Coroutine garbage collection
pypy-dev-issue at codespeak.net
Mon Apr 25 22:52:09 CEST 2011
New submission from Chris Smowton <cs448 at cam.ac.uk>:
I just spent a day trying to figure out a weird bug using coroutines: I think
it'd be useful if the following two counter-intuitive facts were documented:
1. When coroutines are garbage collected, they don't just go away: a
CoroutineExit exception is thrown as if explicitly kill()'d
2. The coroutine will be executed to deal with the exception at next switch, so
that the programmer might not actually end up in the coroutine they expect when
they say "my_coro.switch()".
Of course normally coroutines shouldn't end up garbage; they should be closed
down in an orderly fashion. I ran into this situation when using coroutine
pickle/unpickle to save program state, so old programs which had been pickled
also got GC'd some time later.
In a broader sense, it would be great to a) Attach a 'reason' parameter to
CoroutineExit, as I'd often like to react differently to became-garbage
(probably indicating a bug) compared to explicitly-killed, and b) add a "really
kill" call that stops a coroutine rather than throwing a CoroutineExit
exception; this would be useful in this case where I'm using pickle to
"hibernate" a coroutine.
These are really wishes/feature-requests though; I think the "bug" is that the
current state of the world should be documented.
nosy: pypy-issue, smowton
title: Documentation needed: Coroutine garbage collection
PyPy development tracker <pypy-dev-issue at codespeak.net>
More information about the Pypy-issue