On Mon, Nov 5, 2018 at 6:20 PM <phili...@tura-home.de> wrote: > Again sorry for the confusion, but I don't think this is an issue with > restarting loops, as this isn't happening in my application.
Sure, I wasn't talking about restarting loops so much as strategies for making sure that everything has completed in the first place. > For context: > https://github.com/ldo/dbussy/issues/13 > https://gist.github.com/tu500/3232fe03bd1d85b1529c558f920b8e43 > > It really feels like asyncio is loosing strong references to scheduled > tasks, as excplicitly keeping them around helps. Also, the error > messages I'm getting are the ones from here: > https://github.com/python/cpython/blob/16c8a53490a22bd4fcde2efaf4694dd06ded882b/Lib/asyncio/tasks.py#L145 > Which indicates that the tasks actually weren't even started at all? No, it indicates that it was cleaned up (likely because the program exited) before the task completed. Which likely implies that the loop exited without waiting for it. From the stack trace, you're using loop.run_until_complete(main()). Like asyncio.run, that only runs until the specific thing you pass it completes, which might wait on other things or might not. Anything else that's still pending is going to be left up in the air unless you subsequently restart the same event loop. > Though not really related with my actual problem, so getting off topic, > but I can imagine an architecture where that would be "There aren't any > running tasks any more." or even "Never." Well, "never" is easy; that's just loop.run_forever(). "No more running tasks" is trickier; I'm not sure how one might do that without collecting all the tasks (at least, all the top-level tasks) oneself. Implementing a custom task factory might help. -- https://mail.python.org/mailman/listinfo/python-list
