-
Notifications
You must be signed in to change notification settings - Fork 34.5k
gh-137026: Add an explainer guide for asyncio #137215
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
05b35b0
446534c
176096d
b745f88
0f2b8db
27d1dcd
3852bb1
8bf6d2c
397df8f
84aedf7
3d3e12c
a5fdd0e
b1aef5c
64a12b4
0fffd4b
bfd1212
c946563
3fc668c
ebfe542
3978837
0dd99eb
ff804fe
00a1a68
e982f9c
a033876
dbbc0ab
af9ba25
34f3335
dca3d38
db4ac35
bb8d018
5fdd4e9
fe3c732
1abe9a1
eadc0fb
1f7323d
99ac489
feb8634
49e9c65
daba131
c31f3c5
6756257
a730bd3
8fca2e3
776daeb
0b795a2
d10eeec
b2e90f3
9e07a36
d12b29f
86039b7
e5fafc4
1dc6e51
3c0b0a4
0f3931c
82a1967
9fa9fca
9ff73dc
be9629d
f7dbaa6
689d517
9da27dd
3c0c11c
671cc80
2a96782
def6157
a84827b
01710e2
b5f56f3
3344574
1ed21c0
b574f72
0fbd5b1
27785f3
a75b55b
53ac647
7b5ff84
a8030d6
b4d087a
9e5aaf6
55a268c
43c1c96
1f8f863
ef71d25
4796f85
1000ace
e649c07
d619868
52a90c0
08d4eec
1934aad
7a4eebe
a2fd17a
c944ff1
27c026b
0527218
8adebdc
1422011
a8fa7f6
9d3828d
ee5c4de
9f7d93f
a25b270
7211ef2
4f625b8
673a9f9
270ee6e
e025747
15aa0c5
5b3b697
585521e
6530adc
ac87e24
7e48175
f881bfd
2227e4b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
- Loading branch information
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -12,7 +12,7 @@ You might be curious about some key :mod:`!asyncio` concepts. | |
| You'll be comfortably able to answer these questions by the end of this | ||
| article: | ||
|
|
||
| - What's happening behind the scenes when an object is ``await``\ ed? | ||
| - What's happening behind the scenes when an object is awaited? | ||
| - How does :mod:`!asyncio` differentiate between a task which doesn't need | ||
| CPU-time (such as a network request or file read) as opposed to a task that | ||
| does (such as computing n-factorial)? | ||
|
|
@@ -201,15 +201,15 @@ different ways:: | |
| await task | ||
| await coroutine | ||
|
|
||
| Unfortunately, it does matter which type of object is ``await``\ ed. | ||
| Unfortunately, it does matter which type of object is awaited. | ||
|
|
||
| ``await``\ ing a task will cede control from the current task or coroutine to | ||
| awaiting a task will cede control from the current task or coroutine to | ||
| the event loop. | ||
| In the process of relinquishing control, the task that's giving up control | ||
| adds a callback to the ``await``\ ed task's list of callbacks indicating it | ||
| should resume the current task/coroutine when it (the ``await``\ ed one) | ||
| adds a callback to the awaited task's list of callbacks indicating it | ||
| should resume the current task/coroutine when it (the awaited one) | ||
| finishes. | ||
| In other words, when that ``await``\ ed task finishes, the original task is | ||
| In other words, when that awaited task finishes, the original task is | ||
| added back to the event loops queue. | ||
|
|
||
| This is a basic, yet reliable mental model. | ||
|
|
@@ -218,7 +218,7 @@ In part 2, we'll walk through the details that make this possible. | |
|
|
||
| **Unlike tasks, awaiting a coroutine does not hand control back to the event | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This isn't entirely correct, using tasks does not guarantee that the control will be given to event loop if e.g. the task completes eagerly.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for the clarification. I didn't know about that! You're referring to the We could add a brief note, like: "Unlike tasks, awaiting a coroutine does not hand control back to the event loop (though note that tasks created with eager_start=True may also complete without yielding control)." Though, since this parameter defaults to
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
It's in asyncio.Task only. So I guess it's not a high-level feature that regular users should be using, but it's something we use to optimise in asyncio libraries like aiohttp. Maybe just tweak it to say 'user-created tasks', and try to avoid mentioning eager_start directly?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Ah, oops. My mistake! Thanks for the clarification. Hmm, yeah. That is a nice idea. But I'm worried it may leave folks wondering why non user-created tasks don't fit the mold. |
||
| loop!** | ||
| Wrapping a coroutine in a task first, then ``await``\ ing that would cede | ||
| Wrapping a coroutine in a task first, then awaiting that would cede | ||
| control. | ||
| The behavior of ``await coroutine`` is effectively the same as invoking a | ||
| regular, synchronous Python function. | ||
|
|
@@ -243,7 +243,7 @@ Consider this program:: | |
|
|
||
| The first statement in the coroutine ``main()`` creates ``task_b`` and places | ||
| it on the event loop's queue. | ||
| Then, ``coro_a()`` is repeatedly ``await``\ ed. Control never cedes to the | ||
| Then, ``coro_a()`` is repeatedly awaited. Control never cedes to the | ||
| event loop which is why we see the output of all three ``coro_a()`` | ||
| invocations before ``coro_b()``'s output: | ||
|
|
||
|
|
@@ -404,7 +404,7 @@ We'll go through an example of how you could leverage a future to create your | |
| own variant of asynchronous sleep (``async_sleep``) which mimics | ||
| :func:`asyncio.sleep`. | ||
|
|
||
| This snippet puts a few tasks on the event loop's queue and then ``await``\ s a | ||
| This snippet puts a few tasks on the event loop's queue and then awaits a | ||
| coroutine wrapped in a task: ``async_sleep(3)``. | ||
| We want that task to finish only after three seconds have elapsed, but without | ||
| preventing other tasks from running. | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.