[issue31960] Protection against using a Future with another loop only works with await

Change by Antoine Pitrou : -- resolution: -> postponed stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Python-

[issue31960] Protection against using a Future with another loop only works with await

Yury Selivanov added the comment: I guess you can set Resolution to "postponed", Stage to "Resolved". -- ___ Python tracker ___ ___

[issue31960] Protection against using a Future with another loop only works with await

Antoine Pitrou added the comment: The documentation has been fixed. Should we close this now? Ideally I'd rather have asyncio warn me in such situations, but I feel this won't be doable. -- ___ Python tracker

[issue31960] Protection against using a Future with another loop only works with await

Antoine Pitrou added the comment: New changeset 518c6b97868d9c665475a40567b0aa417afad607 by Antoine Pitrou (Miss Islington (bot)) in branch '3.6': bpo-31960: Fix asyncio.Future documentation for thread (un)safety. (GH-4319) (#4320) https://github.com/python/cpython/commit/518c6b97868d9c665475

[issue31960] Protection against using a Future with another loop only works with await

Antoine Pitrou added the comment: > Maybe the solution is to fix Tornado? That's a possibility. I have to convince Ben Darnell that it deserves fixing :-) Another possibility is to use the asyncio concurrency primitives on Python 3, though that slightly complicates things, especially as the

[issue31960] Protection against using a Future with another loop only works with await

Change by Roundup Robot : -- pull_requests: +4278 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue31960] Protection against using a Future with another loop only works with await

Antoine Pitrou added the comment: New changeset 22b1128559bdeb96907da5840960691bb050d11a by Antoine Pitrou in branch 'master': bpo-31960: Fix asyncio.Future documentation for thread (un)safety. (#4319) https://github.com/python/cpython/commit/22b1128559bdeb96907da5840960691bb050d11a

[issue31960] Protection against using a Future with another loop only works with await

Yury Selivanov added the comment: > Just try the snippet :-) If you want to see it finish in a finite time, move > the future instantiation inside the coroutine. Yeah, I see the problem. OTOH your proposed change to lazily attach a loop to the future isn't fully backwards compatible. It wou

[issue31960] Protection against using a Future with another loop only works with await

Antoine Pitrou added the comment: > So imagine a Future `fut` is completed. And we call `fut.add_done_callback()` > in different contexts with different active event loops. With your > suggestion we'll schedule our callbacks in different loops. I'm wondering: does this situation occur in pra

[issue31960] Protection against using a Future with another loop only works with await

Yury Selivanov added the comment: > My underlying question is why the Future has to set its loop in its > constructor, instead of simply using get_event_loop() inside > _schedule_callbacks(). This would always work. So imagine a Future `fut` is completed. And we call `fut.add_done_callback()

[issue31960] Protection against using a Future with another loop only works with await

Antoine Pitrou added the comment: The call_soon / call_soon_threadsafe distinction is not relevant to the problem I posted. The problem is that the Future is registered with the event loop for the thread it was created in, even though it is only ever used in another thread (with another even

[issue31960] Protection against using a Future with another loop only works with await

Yury Selivanov added the comment: >> I think we should update `Future._schedule_callbacks` to check if the loop >> is in debug mode. > Unfortunately this is not sufficient for the snippet I posted. The loop's > thread_id is only set when the loop runs, but the main loop in that example > ne

[issue31960] Protection against using a Future with another loop only works with await

Change by Antoine Pitrou : -- keywords: +patch pull_requests: +4277 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-li

[issue31960] Protection against using a Future with another loop only works with await

Antoine Pitrou added the comment: My underlying question is why the Future has to set its loop in its constructor, instead of simply using get_event_loop() inside _schedule_callbacks(). This would always work. -- ___ Python tracker

[issue31960] Protection against using a Future with another loop only works with await

Change by STINNER Victor : -- nosy: -haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue31960] Protection against using a Future with another loop only works with await

Antoine Pitrou added the comment: > My opinion on this: update documentation for all Python versions to reflect > that Future uses call_soon. Agreed. > I think we should update `Future._schedule_callbacks` to check if the loop is > in debug mode. Unfortunately this is not sufficient for the

[issue31960] Protection against using a Future with another loop only works with await

Yury Selivanov added the comment: > On the other hand, the Future implementation is entirely not thread-safe > (btw, the constructor optimistically claims the done callbacks are scheduled > using call_soon_threadsafe(), but the implementation actually calls > call_soon()). This is weird. PE

[issue31960] Protection against using a Future with another loop only works with await

Antoine Pitrou added the comment: Guido, Yury, what is your take on this? Do you think it would be fine for Future._schedule_callbacks() to check the event loop is the current one, or do you think it would impact performance too much (or perhaps it is simply not desirable)? -- nosy:

[issue31960] Protection against using a Future with another loop only works with await

Antoine Pitrou added the comment: I'm not sure what the desired semantics for Futures and multiple loops is. On the one hand, there is little point in having two event loops in the same thread at once (except for testing purposes). On the other hand, the Future implementation is entirely no

[issue31960] Protection against using a Future with another loop only works with await

New submission from Antoine Pitrou : If you await a Future with another loop than a loop at instance creation (this is trivial to do accidentally when using threads), asyncio raises a RuntimeError. But if you use another part of the Future API, such as add_done_callback(), the situation isn't