Repository navigation
Provide run_until_complete inside loop #73744
Description
| BPO | 29558 |
|---|---|
| Nosy | @gvanrossum, @asvetlov, @vadmium, @1st1 |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = <Date 2017-12-20.20:29:27.567>
created_at = <Date 2017-02-14.17:17:00.240>
labels = ['type-feature', '3.7', 'expert-asyncio']
title = 'Provide run_until_complete inside loop'
updated_at = <Date 2017-12-20.20:29:27.564>
user = 'https://bugs.python.org/txomon'bugs.python.org fields:
activity = <Date 2017-12-20.20:29:27.564>
actor = 'asvetlov'
assignee = 'none'
closed = True
closed_date = <Date 2017-12-20.20:29:27.567>
closer = 'asvetlov'
components = ['asyncio']
creation = <Date 2017-02-14.17:17:00.240>
creator = 'txomon'
dependencies = []
files = []
hgrepos = []
issue_num = 29558
keywords = []
message_count = 4.0
messages = ['287784', '287800', '287847', '308804']
nosy_count = 5.0
nosy_names = ['gvanrossum', 'asvetlov', 'martin.panter', 'yselivanov', 'txomon']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue29558'
versions = ['Python 3.6', 'Python 3.7']
Activity
txomon commentedon Feb 14, 2017
The current architecture of asyncio makes it really hard to combine both async and sync code.
When porting a Thread based application to asyncio, the first step is usually to start merging threads to the main loop, by using
run_coroutine_threadsafe. This works well and allows to use a single ioloop from different threads.There is another step, that usually involves the patching of libraries to work in an async way. One will typically patch the IO calls to be asyncio, and using
run_until_completeproves useful in these situations.However, at the moment it's not possible to
run_until_completefrom an ioloop. The possibility to be able to patch sync libraries to run in asyncio is something that would help a lot the migration.This functionality would basically provide a way to continue running the ioloop until the future is resolved.
Sync code -> async code -> Sync code -> Async code
If you know how to have this without spawning an executor, that would be good too, in such case I would rather ask for documentation on how to do it =)
vadmium commentedon Feb 14, 2017
Sounds related to bpo-22239
txomon commentedon Feb 15, 2017
Yes, indeed it is. Would it be possible to reconsider this functionality? It plays a key role when trying to rewrite full applications to async.
Rewriting the full stack of libraries at once is impossible, but the patching can easily be done in many cases.
asvetlov commentedon Dec 20, 2017
Awaiting a future from blocking code which in turn is executed from async code is very dangerous idea -- it will block other async code execution.
The feature will be never implemented as well as nested loops, sorry.
Closing.