Async Techniques and Examples in Python Transcripts
Chapter: Built on asyncio
Lecture: Why do we need more libraries?
Login or
purchase this course
to watch this video and the rest of the course contents.
0:00
Before we get to the programming details
0:01
of these additional libraries
0:03
let's talk about why we might need them at all.
0:05
We have async and await. We have threads.
0:08
Isn't that good enough?
0:09
Well, it depends on what you are trying to do.
0:12
Yes, it's good enough, but it can be better
0:14
as we all see. So what are some of the shortcomings
0:16
of the various aspects that we've worked with so far?
0:19
Mostly around asyncio, but also around threads and processes.
0:23
One of the things that's annoying about asyncio is
0:25
you have to have an event loop in order to execute
0:29
an async function. Remember what we did is we created
0:32
a loop, and then we queued up a bunch of work in it
0:34
and where we created some coroutines
0:37
and we said run to completion or something to this effect.
0:40
And we waited on that loop. And it's not that hard
0:44
honestly, but if you have a deep architecture:
0:47
some function, calls another function, calls a library
0:50
which called another function, how do you take the loop
0:52
you have to create at the outside and pass it deep down
0:54
to the inside so async functions down there can run?
0:57
If you need to coordinate across those things
0:59
this can be really not so easy.
1:01
Alright, you end up passing stuff around or having
1:03
weird global variables that, depending on how things
1:06
are working, may actually not even work.
1:08
This is a shortcoming, and we'll see if one of the libraries
1:11
we talk about fixes it.
1:13
So this is the shortcoming, and each of the libraries
1:15
we're going to talk about has a certain way to address this.
1:18
Asyncio.future is not thread-safe.
1:20
Now, that may sound weird to you, but remember
1:22
asyncio doesn't actually use other threads.
1:25
It's like an event loop on a single thread
1:27
so it's not thread-safe.
1:28
But if you want to mix it with threads, that would be better
1:32
if it were, right?
1:33
On the converse side, we have concurrent.future.
1:36
Remember this comes back from the ThreadPoolExecutor
1:38
or ProcessPoolExecutor?
1:40
When we queue up work, that thing cannot be used with
1:43
async and await. It cannot be directly awaited
1:46
which is annoying. Wouldn't it be great if I could
1:48
get one of those back and mix it in and await on it?
1:52
Well, you can't. Future.result is a blocking operation.
1:57
It's generally good. If it's not done
1:58
you want to get the work back.
2:00
However, if you're doing this in an event loop
2:02
you could actually clog up the event loop
2:05
and if somehow there's a loop
2:07
you somehow create the future
2:09
which is running the event loop
2:10
and then you call a block on it on another slice of
2:13
those tasks running there
2:15
you will deadlock your event loop.
2:16
Not great. On the other hand
2:18
where future.result is a blocking operation
2:21
asyncio.future.result will actually throw an exception
2:25
if you haven't completely waited for it to be done.
2:28
So, depending on which type future you have
2:31
it doesn't behave the same, that's also hard
2:33
so we'll see of unifying stuff happening here.
2:36
Async functions, as in async def - that's a function name
2:39
always execute in asyncio loop. They don't run in threads.
2:44
They won't run in multiprocessing mode.
2:47
None of those types of things.
2:49
However, may we have some work, and some of it is based on
2:52
asyncio, but other parts of that work that we're trying
2:55
to do altogether might be computational.
2:58
Or maybe it's working with something that talks to a
3:00
database or network, but that library doesn't support
3:03
asyncio directly.
3:05
It would be nice if we didn't have to completely
3:07
have different API's and ways of working with them
3:10
if we could unify that. Well, cancellation and timeout
3:14
are tricky things than threads and processes.
3:17
Thread local storage, which we have not talked about
3:19
does not work for asyncio concurrency.
3:22
So thread local storage is kind of like a global variable
3:25
but each thread has its own copy of that data.
3:30
Each thread has its own values for that global data.
3:34
Imagine something like Flask.
3:37
Flask has a global request object, and each time a
3:40
request comes in, you can just access it out of thin air
3:44
in your view method. And it has the value of that particular
3:47
request. And that's fine if it's single threaded.
3:50
You can just set that value, do the function call
3:53
and then unset it.
3:55
But remember, asyncio has only one thread for all these
3:59
interwoven operations. So thread local storage no longer
4:02
means what it used to mean.
4:04
Well see, none of the libraries here directly address this
4:07
but further down the line when we get to the async web stuff
4:11
that's one of the problems that's going to have to be addressed.
4:14
Testing concurrent code can also be tricky.
4:17
These are some of the shortcomings that the libraries
4:20
we were talking about will help us address
4:22
and they also bring their own cleaner programming API
4:25
for certain things that they're built for:
4:27
coordination, parent/child tasks, things like that.
