What Is asyncio?

If I understand it (I hope), I add some things to the diagram, some feedback about its validity is appreciated.

asyncio.png

I have another questions about the execution model presented in the diagram, my confusion arise from the distinction between multithreading and coroutine. Please, let me know if I am wrong and why:

In the diagram, the request is made by a coroutine and managed by the event loop, instead of waiting for the response, the coroutine voluntarily stop his own execution and pass/yield control to other coroutine o subprocess. This process is known as cooperative multitasking.

Until here, the next doubts don’t let me sleep (lol):

• Does the coroutine is aware of the external world or just don’t care?
• How context switching happens between coroutines? I think that the OS is in charge of this in preemptive multitasking and only apply for threads.
• What happens if the coroutine doesn’t yield for any reason.
• Finally, coroutine switching take place between what? I know, a coroutine but … is this a process or a subprocess? I think is between a subprocess, therefore I asume that coroutines share the same resources.

So what is the difference with multithreading? JAJAJA this is so difficult lol.

@usuarioman Don’t worry. It can be challenging to wrap your head around coroutines when you first learn about them. Let me try to answer your questions.

Is the coroutine aware of the external world or doesn’t care?

A coroutine is a piece of code enclosed in a function that can halt and resume its execution multiple times. Unless you provide some context through an argument or a global variable, it won’t know anything about the external world.

How does context switching happen between coroutines? The OS is in charge of this in preemptive multitasking and only applies to threads.

Coroutines don’t fall under the category of preemptive multitasking. They use cooperative multitasking, which means they voluntarily give up (or not) CPU time. You decide when, how often, and to whom switch the context using the yield keyword followed by another coroutine’s name. It makes the code much easier to follow and debug because context switching points are deterministic and known upfront.

What happens if the coroutine doesn’t yield for any reason?

In the old days, you had to use frameworks such as Twisted or Tornado to artificially turn generator functions into coroutines since they weren’t natively supported by the language at the time. Such functions had to use the yield keyword inside their body to become coroutines. Otherwise, they were just regular functions.

Today, you can declare a coroutine by marking a function with the async keyword:

async def main():
    print("hello world")

In most cases, you’ll want to use its twin brother, the await keyword, to “yield” or halt the execution and switch the context to another coroutine without blocking the main thread, for example:

import asyncio

async def main():
    await asyncio.sleep(1)
    print("hello world")

However, awaiting another coroutine isn’t mandatory. It’s just that such coroutines won’t take advantage of asynchronous execution provided by the event loop.

Coroutine switching takes place between what?

Whether you’re talking about processes, threads, or coroutines, context switching boils down to allocating CPU time to one of those resources. Processes and threads are typically managed by the operating system’s scheduler, which forcefully halts their execution, hibernates their state, and takes away CPU for a fraction of time. The exact moment of a context switch, its duration, and the next process or thread to resume execution remains unknown.

Coroutines, on the other hand, voluntarily give up CPU time at predictable moments and to specific coroutines that they call out by name. There’s no need for a scheduler.

So what is the difference with multithreading?

Both threads and coroutines let you run code concurrently. Even though threads are a system-level resource, which could take advantage of multiple CPU cores, the Global Interpreter Lock (GIL) in CPython makes all threads run on a single core at a time. Therefore, neither threads nor coroutines can run truly in parallel in Python. They’re only good for so-called I/O-bound tasks, which involve a lot of waiting for data over the network or disk. When there’s nothing to do, another thread or coroutine will make better use of the CPU.

Both share memory within a single process, making them more lightweight than full-blown OS processes. However, threads are more heavyweight than coroutines. Typically, you can have thousands of I/O-bound threads in a single process and tens of thousands of coroutines to handle HTTP requests, for example.

The downside of using coroutines is that they can’t call blocking operations. Most of the standard library in Python is comprised of blocking functions. You need to be careful to use their non-blocking counterparts if available or find a third-party library as a substitute. If that fails, you might wrap a blocking call in a thread.

W0o0ow … thank you a lot for your answer, this is amazing !! Thanks, I have a better understanding now, you are the best!