[BUG] The `onAccept` exception occurred with a write event.

[baigao-X]

Phenomenon Description

The tested version has completed the patch fix mentioned in issue #2946 in the ZLMediaKit project. However, during testing, a write event still occurred within the onAccept interface.

Analyzing the code, I believe there is a event cache issue mentioned in the epoll man manual. Here is my analysis of the possible logic that triggers the exception (please correct me if my analysis is wrong):

• When calling epoll_wait, multiple events will be returned. Assuming the current returned event descriptors are [10, 11, 12]. EventPoll will process the callbacks in order.
• The callback processing for descriptor 10 is to release a UDP service, which will release descriptor 12 (at the same time calling delEvent, removing descriptor 12 from _event_map).
• The callback processing for descriptor 11 is to create a TCP service, which is assigned to the newly released descriptor 12 (at the same time calling addEvent, adding descriptor 12 to _event_map).
• At this point, the event processing for descriptor 12 may be a callback function and descriptor object that do not match the old descriptor.

When a write event is thrown to the onAceept callback, it will cause a particularly serious exception (dead loop).

How to reproduce?

It is likely to occur when openRtpServer and closeRtpServerAPi are called frequently.

现象描述

测试的版本已经完成了 ZLMediaKit 项目中issue #2946 中提到的补丁修复。 但是在测试时依然在onAccept接口内出现了write事件。

分析代码我想是存在epoll man手册中提及的 event cache 问题 以下是我分析的可能触发异常逻辑(分析如有不对，请斧正)

• 当调用epoll_wait 时，将返回多个事件。假设当前返回的事件描述符分别是 [10, 11, 12]。EventPoll将按顺序依次处理回调
• 描述符 10 的回调处理是 释放一个UDP服务，这将释放描述符12（同时调用delEvent, 将描述符12从_event_map 中的删除）
• 描述符 11 的回调处理 是创建TCP服务，它分配到了新释放的描述符12（同时调用addEvent, 将描述符12在_event_map 中的增加）
• 此时处理描述符12的事件的将可能是一个与旧描述符不相符的回调函数与描述符对象。

当一个写事件抛给onAceept回调时将引起特别严重的异常(死循环）

如何复现?

频繁调用openRtpServer 和closeRtpServerAPi时，有几率发生。

TRANS_BY_GITHUB_AI_ASSISTANT

[xia-chu]

Indeed, this issue exists. However, this issue does not exist in select mode because select mode first traverses and saves PollEventCB. epoll mode does not cache PollEventCB before execution.

确实存在这个问题 不过这个问题在select模式下不存在 因为select模式先遍历并保存PollEventCB epoll模式不会缓存PollEventCB再执行

TRANS_BY_GITHUB_AI_ASSISTANT

[baigao-X]

Indeed, this problem does not exist in the select mode.

However, I think that since delEvent has already been called, it means that the event is no longer relevant, and there is no need to waste time executing the event callback.

Therefore, I still added this filter in the select branch.

确实select模式下不会存在这个问题。 但是我想既然已经调用了delEvent，说明这个事件已经不关心了，也就没必要浪费再去执行这个事件回调了。 因此在select分支中我还是加上了这层过滤。

TRANS_BY_GITHUB_AI_ASSISTANT