blocks|key|120132|text|协程不需要事件循环。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|120133|当计算机读取co_await时，它会跳转到称为协程的函数，并保存它的所有帧(局部变量、值等等)。|offset|length|style|CODE|120134|这里的神奇之处在于，下一次调用协程时，您会回到这种状态。正如你所看到的，不需要事件循环，只需要一个地方来存储这个帧。|120135|entityMap^0|0|6|8|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

Coroutines do not need an event loop.
When the computer reads <code>co_await</code> what happens is that it will jump to the function which called the coroutine and save all of its frame (the local variables values and so on).
The magic here is that the next time you call the coroutine you come back to this state. As you can see there is no need for event loop, only a place to store this frame.

blocks|key|3899681|text|Python和JavaScript不处理CPU线程(好吧，Python可以处理线程，但这里不相关，因为Python线程本身并不是可等待的)。所以他们用“事件循环”来伪装线程。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3899682|C%2B%2B是一种低级语言，它知道什么是CPU线程，并期望使用它们。因此，当您在某个表达式上执行co_await时，您通常是在等待(可能)在另一个线程中发生的进程。|offset|length|style|CODE|3899683|当然，您可以使用事件循环来伪造线程，并创建一些使用事件循环处理的可等待类型。但这通常不是C%2B%2B程序员对异步处理所做的事情。|3899684|在C%2B%2B协程中，恢复执行协程的方式完全取决于您所使用的可等待类型。它控制着函数恢复的调度。C%2B%2B中的大多数可等待对象将使用某种形式的CPU线程(最常见的方法是在执行它正在等待的异步进程的线程上调用协程)。其他的可能有某种类型的事件循环或其他东西。但重点是，这是产生你所等待的值的东西的函数，而不是协程本身。|3899685|entityMap^0|0|19|8|0|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@$D|P|E|Q|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|R|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|S|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|M|$]]

Python and JavaScript don't do CPU threads (well, Python can do threads, but that's not relevant here, because Python's thread stuff isn't inherently await-able). So they fake threading with &quot;event loops&quot;.
C++ is a low-level language that knows what CPU threads are and expects to make use of them. As such, when you <code>co_await</code> on some expression, you are typically awaiting on a process that is (potentially) happening in another thread.
You certainly can fake threading with an event loop, and create some awaitable type that uses event loop processing. But that's not typically what C++ programmers do with asynchronous processing.
In C++ coroutines, the way the resumption of execution of a coroutine works depends entirely on the awaitable type you're using. It governs the scheduling of the function's resumption. Most awaitables in C++ will use some form of CPU threading (the most common method being to invoke the coroutine on the thread performing the async process it is waiting on). Others may have some kind of event loop or whatever. But the point is that this is a function of the thing which produces the value you're waiting on, not the coroutine itself.

blocks|key|661295|text|C%2B%2B中没有事件循环，线程与协程的关系也很小。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|661296|当您在C%2B%2B中执行co_await时，函数的执行被挂起，代码继续执行调用者，就像函数已经返回一样。实际上，它是这样实现的。co_await将更改协程的内部状态机并返回。|offset|length|style|CODE|661297|当代码显式恢复函数时，将恢复执行。|661298|这就是协作多任务处理。对执行的控制是显式的和可预测的。|661299|现在，使用大多数库，您不必回调要恢复的协程。这就是执行者的用武之地。它们有点像事件循环，但在库中，而不是在语言中烘焙。用户代码也可以实现它们，您可以针对不同的用例使用不同的代码。它们通常会调度协程的执行，也可以管理多个线程来一次执行其中的许多线程。|661300|例如，您可以完全在线程池的顶部实现一个executor。等待io的大型操作不需要为自己阻塞线程，它将启动io操作并将线程返回给其他任务。在内部，io操作将把协程调度回线程池中进行恢复。|661301|另一个例子是linux上的io_uring，它是新的async+io+api。您可以使用executor包装工具，并将io操作作为协程运行。从技术上讲，你不需要线程来做这件事。对co_await的调用将简单地调度io操作，一旦内核将结果入队，协程将恢复。|661302|entityMap^0|0|9|8|1P|8|0|0|0|0|0|2H|8|0^^$0|@$1|2|3|4|5|6|7|T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|U|8|@$D|V|E|W|F|G]|$D|X|E|Y|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|10|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|11|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|12|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|13|8|@$D|14|E|15|F|G]]|9|@]|A|$]]|$1|R|3|-4|5|6|7|16|8|@]|9|@]|A|$]]]|S|$]]

There is no event loop in C++ and threads have very little to do with coroutine either.
When you <code>co_await</code> in C++, the execution of the function is suspended and the code continue to execute the caller, just as if the function had returned. In fact, it is implemented this way. <code>co_await</code> will change the internal state machine of the coroutine and will return.
The execution is resumed when the code explicitly resumes the function.
This is cooperative multitasking. Control of the execution is explicit and predictable.
Now, using most libraries you won't necessarily have to call back the coroutine to be resumed. This is where executors comes in. They are a bit like event loops but inside a library instead of baked in the language. User code can implement them as well, and you can have different one for different use cases. They will usually schedule the execution of coroutines and can also manage multiple threads to execute many of them at once.
For example, you could totally implement an executor on top of a thread pool. Large operation that wait on io won't need to block the thread for themselves, it will start the io operation and give back the thread to other tasks. Internally, the io operation will schedule the coroutine back into the thread pool to be resumed.
Another example would be io_uring on linux, which is the new async io api. One could wrap the facility with an executor and run io operation as coroutines. Technically, you don't need threads to do this one. Calls to <code>co_await</code> will simply schedule the io operation and the coroutine will resume once the kernel has enqueued a result.

blocks|key|120241|text|事件循环对于事件驱动的应用程序来说是很棒的，在事件驱动的应用程序中，除非发生一些外部事件，否则什么都不做。对于早期的基于X11的程序来说，这是很常见的，这些程序会显示一些东西，然后等待操作员选择或操作小部件，例如滑块或最小化小部件，然后将事件传递给C事件处理程序。稍后，我们为事件设置回调，以使事件处理程序更加流畅。这在当今的IoT编程中非常常见。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|120242|异步处理是不同的。异步处理启动一个线程去做一些事情，所有的进程关心的是它已经完成了，可能还有一个返回值。基本上，它可以防止进程在某个操作发生时被阻塞。|120243|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Event loops are great for event driven applicaitons where you literally do nothing until some external event occurs. This was common for early X11 based programs that would display something and then waits for the operator to select or manipulate a widget, such as a slider bar or minimize widget, and the event would be passed to the c event handler. Later we setup up callbacks for events to make the event handler more streamlined. This is very common in IoT programming today.
Async processing is different. Async processing starts a thread to do something and all the process cares about is that it was done and possibly a return value. Basically it prevents the process from being blocked while an action is occurring.

For someone who has some async experience from other languages (Python/JavaScript), when talking about async/await there is always an assumption that there is an event loop somewhere. But for C++ I have looked through the documentation and have not found anywhere talking about the event loop. Why is this the case?
For Node, it only has one default event loop. For Python you can create multiple ones if you want. But for C++ is this event loop assumed like Node? Or for some reason, do we not need it at all?

Why does C++'s async/await not need an event loop?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

对于对其他语言(Python/JavaScript)有一定异步经验的人来说，当谈论异步/等待时，总是会假设在某个地方有一个事件循环。但是对于C++，我已经浏览了文档，没有找到任何讨论事件循环的地方。为什么会这样呢？对于Node，它只有一个默认的事件循环。对于Python，如果需要，您可以创建多个。但是对于C++，这个事...

问为什么C++的异步/等待不需要事件循环？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么C++的异步/等待不需要事件循环？EN