Understanding of Event::defer() in combination with Event-loop's Tick

[fakharanwarcom-prog]

I am trying to understand use cases of Event::defer() however no source on internet (including Swoole's Documentation) is able to explain it, precisely.

Same is for Event-Loops' tick.

Event::defer() delays the execution of the code after the current on-giong Event Loop tick / iteration, (or, before the start of next iteration / tick).

Question-1: What is / are the good use case/s which can help understand the significance of doing that Event:defer() ? In other words, what we can achieve from doing that Event::Defer() ?

Question-2:
Does one Tick (which i assume as one iteration) of Event Loop, triggers the handling of multiple different "Types" of I/O-Events (like all pending onConnect and on open reqeuests and pending onMessage events and pending onClose and pending onDisconnect events) in each single Tick (Iteration) ? OR each "Type" of I/O-event executes in different iteratoins ?

Quetion-3:
When onMessage handler is triggered for each "fd" as part of a Event-loop's Tick, do the Coroutine's, which we create inside handler (Callback), also trigger within same tick ?

Question-4:
When i call an Event:defer() from inside an onMessage callback (handler), will it run only once (globally) for all Messages for all Fds ?
OR
It will run for each fd by retaining the context of Message (which means, by retaining the data sent to that fd, in the current message) ?

[NathanFreeman]

For question one, you can understand Swoole\Event::defer() as follows: it postpones the execution of a callback function until the end of the current event loop iteration. Simply put, it is the first task to be executed at the next available moment, after all tasks at the current moment have been completed.

This mechanism is typically used to ensure that a time-consuming task, or a task that needs to be executed later, does not interfere with more urgent tasks at hand. It is suitable for handling tasks that do not need immediate execution but cannot be omitted. For example, if you want to record operation logs but are concerned that logging might occupy the execution time of the current request, you can use this to postpone the log recording operation.

Additionally, there is Swoole\Coroutine::defer(), which works similarly, but its execution timing is before the coroutine is destroyed. It is suitable for releasing resources acquired during the coroutine's execution, such as closing connections or cleaning up temporary files, ensuring that resources are properly handled.

[NathanFreeman]

For question two, your understanding is correct.

In one tick (iteration) of the event loop, Swoole processes all I/O events from different file descriptors (fds) that are ready at that moment. This means that within a single tick, multiple different types of callbacks can indeed appear and be executed alternately.

The specific analysis is as follows:

1. Polling Mechanism of the Event Loop: Swoole's event loop is based on the underlying I/O multiplexing mechanism (such as epoll / kqueue / select). When a tick begins, the Swoole kernel initiates a poll to the underlying system, asking: "Which file descriptors (fds) have events occurring now?"

2. Batch Event Retrieval: This poll may return a batch of events that are already ready. This batch of events constitutes the content to be processed in the current tick. These events can come from completely different client connections (different fds) and can also be different types of network events.

3. Mixed Event Types: As you mentioned, when a connection (fd1) is just established, it triggers onConnect; when another connection (fd2) sends data, it triggers onReceive or onMessage; if a certain connection (fd3) disconnects, it triggers onClose. If these events occur at the same time, the underlying operating system will notify Swoole of them all at once. Swoole will then execute the callback functions for onConnect, onMessage, and onClose sequentially within this single tick.

[NathanFreeman]

For question three, your understanding is not entirely accurate.

The actual situation needs to be distinguished based on whether there are I/O operations within the coroutine:

If the coroutine created in the onMessage callback has no I/O operations at all (purely computational tasks), then this coroutine will indeed complete its entire lifecycle within the same tick—from creation, execution, to destruction, all finished in one go during the current event loop iteration.

However, if the coroutine contains I/O operations (such as database queries, file reading/writing, HTTP requests, etc.) and one-click coroutineization has been enabled, the situation is different. When the coroutine executes an I/O operation, it will actively yield (give up the CPU), returning control to the event loop so it can handle other ready events or schedule other coroutines. At this point, the current coroutine enters a waiting state until the I/O operation completes.

It's important to note that during the time the coroutine is suspended waiting for I/O, the event loop may have already gone through many ticks. When the I/O operation finally completes, Swoole will wake up the coroutine in some future tick, allowing it to continue executing the remaining code.

In simple terms:

• Coroutines without I/O: Execute completely within the current tick.
• Coroutines with I/O: Yield at the I/O point and span multiple ticks to complete.

[NathanFreeman]

Regarding question four, your understanding needs a slight adjustment. The execution timing of Swoole\Event::defer() is fixed: It executes once after each event loop tick ends and before the next tick begins.

It does not trigger execution separately for each file descriptor (fd). Suppose 100 fds trigger the onMessage event within a single event loop tick. No matter how many times Swoole\Event::defer() is called during these 100 onMessage executions, the callbacks registered via defer() will not execute immediately. Instead, they are temporarily stored in a queue. When the current tick ends, Swoole will retrieve all tasks from this queue at once and execute them sequentially.

In the scenario you described, because defer() is called within onMessage, if all 100 onMessage events execute this line of code, it effectively means 100 callback functions have been added to the queue during the current tick. Therefore, when this tick ends, these 100 callbacks will be executed one after another, and you will ultimately see 100 output results produced by Swoole\Event::defer().

[fakharanwarcom-prog]

Thank you @NathanFreeman The answers are very well understood for the first time, as explained concisely and precisely.

This valuable pearl of information should be updated in official documentation and this thread of discussion should stay opened, for some time, as the discussion can be extended in future, when required.