This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author richard.kiss
Recipients giampaolo.rodola, gvanrossum, pitrou, richard.kiss, vstinner, yselivanov
Date 2014-04-06.02:12:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1396750363.78.0.331918449081.issue21163@psf.upfronthosting.co.za>
In-reply-to
Content
You were right: adding a strong reference to each Task seems to have solved the original problem in pycoinnet. I see that the reference to the global lists of asyncio.tasks is a weakset, so it's necessary to keep a strong reference myself.

This does seem a little surprising. It can make it trickier to create a task that is only important in its side effect. Compare to threaded programming: unreferenced threads are never collected.

For example:

f = asyncio.Task(some_coroutine())
f.add_callback(some_completion_callback)
f = None

In theory, the "some_coroutine" task can be collected, preventing "some_completion_callback" from ever being called. While technically correct, it does seem surprising.

(I couldn't get this to work in a simple example, although I did get it to work in a complicated example.)

Some change between 3.3 and 3.4 means garbage collection is much more aggressive at collecting up unreferenced tasks, which means broken code, like mine, that worked in 3.3 fails in 3.4. This may trip up other early adopters of tulip.

Maybe adding a "do_not_collect=True" flag to asyncio.async or asyncio.Task, which would keep a strong reference by throwing it into a singleton set (removing it as a future callback) would bring attention to this subtle issue. Or displaying a warning in debug mode when a Task is garbage-collected before finishing.

Thanks for your help.
History
Date User Action Args
2014-04-06 02:12:43richard.kisssetrecipients: + richard.kiss, gvanrossum, pitrou, vstinner, giampaolo.rodola, yselivanov
2014-04-06 02:12:43richard.kisssetmessageid: <1396750363.78.0.331918449081.issue21163@psf.upfronthosting.co.za>
2014-04-06 02:12:43richard.kisslinkissue21163 messages
2014-04-06 02:12:42richard.kisscreate