c# - 使用 select() 的异步 .NET 套接字和标准套接字：为什么 select() 会阻止异步回调的发生？

Question

我有一个用 C++/CLI 编写的应用程序，它使用了一个用 C# 编写的库。该应用程序是使用标准套接字 API 编写的，并使用 select() 来复用一堆普通的非异步套接字。但是，第三方库使用 .NET 套接字并使用异步结果和回调。

这是场景：我在主线程（一个主要使用本机样式代码的 C++/CLI 应用程序）中创建了一堆常规套接字。我创建了第三方库供应商的 C#“会话”对象，该对象在内部有一堆来自 .NET 类的异步套接字。

我注意到的是，如果我在实例化 C#“会话”对象的主线程中将 NULL 超时参数放入 select() 中，则根本不会为它们的 .NET 套接字进行异步回调。如果我使用 1 秒的超时时间，并且在我的非异步套接字上没有发生其他活动，那么在 select() 超时之前不会传递异步套接字回调。

不知何故， select() 正在阻止回调发生在 .NET 套接字上。我该如何避免这种情况？是否有一些替代的轮询方法可以用于旧的套接字，仍然允许 .NET 套接字传递它们的异步回调？

Answer 1

我找到了解决方案。

在 .NET 中使用的 AsyncCallbacks 中，你不能有任何阻塞的函数，包括 send()/recv() 函数——即使它们是非阻塞的[1]（至少根据我自己的测试）。在 AsyncCallback 中调用阻塞函数，行为未定义。一旦我从代码中摆脱了这种“不确定性”，事情就开始正常工作了。

我通过编写一些将 select() 换成 WaitForMultipleObjectsEx() 的策略类重新模板化了我的类，并通过在 AsyncCallback 中放置一个 SetEvent() 来触发多路复用来解决该问题。这似乎解决了大部分问题。

[1] 编辑：见下面的评论。我是否在非阻塞或阻塞套接字上使用 send() 似乎对“破坏事物”和进入未定义的行为没有影响。