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 Ilya.Kulakov
Recipients Ilya.Kulakov, gvanrossum, r.david.murray, vstinner, yselivanov
Date 2016-05-09.15:28:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> You don't know what else that coroutine is waiting for, and it may be waiting for some I/O whose socket is registered with the other event loop. Since the other event loop won't make progress, you'd be deadlocked.

As an end user I know what my coroutines may be waiting for. It's out of question to expect an ability to reuse coroutine and its associated context in multiple loops.

> PS. If you have something you sometimes want to run synchronously and sometimes as a coroutine, you probably need to refactor it somehow.

We have a service that is responsible for reporting various stages about our application's lifetime. Most of the time app does not care about when (and whether) data will be actually sent, so we run this service in its own thread, the rest of the app just schedules coroutines in its event loop (hidden and managed by service's API). However sometimes it does care and moreover needs to do that synchronously (i.e. when we handle fatal / unhandled exception. In order to reuse remaining code that constructs coroutines, in the place of invocation we create a temporary event loop and use run_until_complete.

This is all practical problem. The conceptual problem is that current API is not flexible enough to create an event policy that would do something more useful that changing default type of an event loop.

Having the ability to get currently running event loop from within executing coroutine sounds pretty convenient and in my opinion would greatly reduce the amount of passing loops everywhere for end users (library developery, unfortunately, have no chance to avoid this).
Date User Action Args
2016-05-09 15:28:09Ilya.Kulakovsetrecipients: + Ilya.Kulakov, gvanrossum, vstinner, r.david.murray, yselivanov
2016-05-09 15:28:09Ilya.Kulakovsetmessageid: <>
2016-05-09 15:28:09Ilya.Kulakovlinkissue26969 messages
2016-05-09 15:28:08Ilya.Kulakovcreate