我的 KLM 内部有一些 Linux 内核中的内核线程。
我有一个服务器线程，它监听通道，一旦它看到有一个传入连接，它就会创建一个接受套接字，接受连接并产生一个子线程。它还将接受的套接字作为 (void *) 参数传递给子内核线程。
代码工作正常。我有一个设计问题。
假设现在必须终止线程，主线程和子线程，关闭接受套接字的最佳方法是什么。我可以看到两种方法，
1]主线程等待所有子线程退出，每个子线程在退出时关闭接受套接字，最后一个子线程将信号传递给主线程以使其退出。在这里，即使主线程是创建接受套接字的线程，子线程也会关闭该套接字，并且它们会在主线程退出之前执行此操作。那么这是可以接受的吗？你们在这里预见到任何问题吗？
2] 其次是主线程在退出之前关闭它创建的所有接受套接字。但是可能存在（极端情况）主线程出现异常并且必须关闭的可能性，因此如果它在退出之前关闭接受套接字，则使用该套接字的子线程将处于危险之中。
因此，我使用的是我提到的第一个案例。让我知道你们的想法？
首先：套接字的“句柄”是一个整数，无论上下文如何，将整数交给 close 函数都会起作用。
关于你的设计..我建议混合使用这两个版本..创建一个打开套接字的列表（如果访问当然会锁定）并让每个线程关闭它的套接字并将其从主列表中删除。退出主线程后，您将关闭所有剩余的套接字。这样子线程+主线程将不得不在套接字打开之前死亡，这应该是所有描述的情况中概率最小的。
我更喜欢选项 1，因为它是一个更清洁的解决方案：当一个特定的线程退出时，它会清理它拥有的资源（线程确实拥有套接字，对吗？）。这样你就不会遇到你提到的任何可能的极端情况，主线程关闭可能在子线程中使用的套接字等。使用子线程拥有套接字并且是唯一一个读/写/关闭它很简单，干净，并导致更高的凝聚力。
可以实现第二个选项以避免具有额外逻辑和信号的极端情况，但实际上没有必要添加额外的复杂性。我总是喜欢使用KISS 原则。
至于您对在与其创建位置不同的线程中关闭套接字的担忧：这里没有问题。文件描述符（用于套接字和其他实体）在整个进程中是唯一的。如果我们谈论的是分叉进程，那将是不同的。