While reading the libuv documentation, I had some questions about pending and poll phases of Event Loop. In the Design Overview section they are described as follows:

在阅读libuv文档时，我对Event Loop的挂起和轮询阶段有一些疑问。在设计概述部分中，对它们进行了如下描述：

1. Pending callbacks are called. All I/O callbacks are called right after polling for I/O, for the most part. There are cases, however, in which calling such a callback is deferred for the next loop iteration. If the previous iteration deferred any I/O callback it will be run at this point.

...

7. Poll timeout is calculated. Before blocking for I/O the loop calculates for how long it should block. These are the rules when calculating the timeout.

   
   



8. The loop blocks for I/O. At this point the loop will block for I/O for the duration calculated in the previous step. All I/O related handles that were monitoring a given file descriptor for a read or write operation get their callbacks called at this point.

   
   

My main question is: poll timeout only limits the time to wait for new events from the system event notification mechanism or it limits the total execution time available to the poll phase?

我的主要问题是：轮询超时只限制等待来自系统事件通知机制的新事件的时间，还是它限制了轮询阶段可用的总执行时间？

Based on the answer to this question, I can assume several scenarios.

根据这个问题的答案，我可以假设几种情况。

Scenario 1

The timeout only limits the time to wait for events from the system event notification mechanism:

超时仅限制等待来自系统事件通知机制的事件的时间：

1. Pending Callbacks are called.


2. Poll timeout is calculated.


3. Libuv subscribes to the system event notification mechanism and puts all events that have occurred into the poll queue. When a timeout is reached, it moves to the next step.


4. Then it executes all callbacks from the poll queue. When the poll queue is empty it moves on to the next step.

This is how I understand the execution of the pending and poll phases in libuv, also, something similar to this scenario is described in the NodeJS documentation

这就是我对libuv中挂起和轮询阶段的执行的理解，NodeJS文档中也描述了类似于此场景的内容

If this scenario is correct, I have a question for step three: Does Libuv continuously wait for events from the event notification mechanism until a timeout is reached, or it does take some breaks to process the events from the poll queue?

如果这个场景是正确的，我有一个关于第三步的问题：Libuv是否持续等待来自事件通知机制的事件，直到到达超时，或者它确实需要一些休息来处理来自轮询队列的事件？

Scenario 2

Some authors say that timeout limits the total execution time of the poll phase, and callbacks from the poll queue that ran out of time are placed in the pending queue.

一些作者说，超时限制了轮询阶段的总执行时间，来自轮询队列的超时回调被放置在挂起队列中。

1. Pending callbacks are called.


2. Poll timeout is calculated.


3. Poll phase executes until timeout is reached.


4. Callbacks from the poll queue that ran out of time due to timeout are placed in the pending queue to be executed at the next iteration of the Event Loop.

If this scenario is correct, how does libuv calculate the time required to execute a callback? Or it just checks the timeout and if it is not exceeded, it runs the callback without paying attention to the time it takes to execute?

如果这个场景是正确的，那么libuv如何计算执行回调所需的时间？或者它只检查超时，如果没有超过，它就运行回调，而不注意执行所需的时间？

Questions

My general questions is:

我的一般问题是：

• Which of the scenarios is closer to the truth or they are both incorrect?


• Does poll queue callbacks are handled if poll timeout is zero?


• What is the purpose of pending queue and when does a handler from the poll queue end up in the pending queue?


• Also, some authors say that callbacks of thread pool operations go to the pending queue, instead of poll queue. Is that correct?

Libuv's event loop can sometimes be a bit complex to understand, but I'll do my best to clarify your questions.

Libuv的事件循环有时可能有点复杂，但我会尽最大努力澄清您的问题。

Scenario 1:
The poll timeout in Libuv typically limits the time to wait for new events from the system event notification mechanism. Your understanding of the execution steps is mostly correct. Libuv will wait for events from the event notification mechanism until the timeout is reached. If the timeout is reached before any events occur, it will move on to executing any pending callbacks. It will not take breaks to process events from the poll queue while waiting for events from the system notification mechanism because that would defeat the purpose of efficient event-driven I/O.

场景1：Libuv中的轮询超时通常会限制等待来自系统事件通知机制的新事件的时间。你对执行步骤的理解基本上是正确的。Libuv将等待来自事件通知机制的事件，直到超时。如果在任何事件发生之前达到超时，它将继续执行任何挂起的回调。在等待来自系统通知机制的事件时，不需要中断来处理轮询队列中的事件，因为这将违背高效的事件驱动I/O的目的。

Scenario 2:
This scenario is not entirely accurate. Libuv's poll timeout usually limits the time spent waiting for events from the system event notification mechanism. If the timeout is reached before any events occur, it will move on to execute pending callbacks. Callbacks from the poll queue are typically executed during the poll phase, and they don't get placed in the pending queue based on execution time. Libuv doesn't have a built-in mechanism to monitor the execution time of individual callbacks and move them to the pending queue based on that.

场景2：这个场景并不完全准确。Libuv的轮询超时通常会限制等待来自系统事件通知机制的事件所花费的时间。如果在任何事件发生之前达到超时，它将继续执行挂起的回调。来自轮询队列的回调通常在轮询阶段执行，并且它们不会根据执行时间被放置在挂起队列中。Libuv没有内置的机制来监控各个回调的执行时间，并基于此将它们移动到挂起队列。

To address your specific questions:

要回答您的特定问题，请执行以下操作：

1. Scenario 1 is closer to the truth. Libuv waits for events from the
   system event notification mechanism until the timeout is reached,
   and it doesn't take breaks to process events from the poll queue.

   
   



2. Callbacks in the poll queue are usually handled during the poll
   phase, and the poll timeout primarily limits the time waiting for
   new events from the system event notification mechanism. If the poll
   timeout is zero, Libuv may not wait at all and will immediately move
   on to execute pending callbacks.

   
   



3. The purpose of the pending queue is to handle callbacks that are scheduled to run later, typically callbacks that were scheduled during the current event loop iteration or deferred callbacks from previous iterations.

   
   



4. Thread pool operations, such as those used for file system operations or certain asynchronous tasks, do not go directly to the poll queue. Instead, they are typically handled by separate worker threads. Results or completion callbacks from these thread pool operations may be posted to the event loop's pending queue for execution once the main event loop is ready to handle them. This is separate from the poll phase.