为什么SO_RCVTIMEO从侦听套接字继承到接受的套接字？

Question

我找不到任何这文件除了从一些Python documentation

18.1.4.2。超时和接受方法

如果getdefaulttimeout()不是None，则由accept()方法返回的套接字将继承该超时。否则，行为取决于侦听套接字的设置：

如果侦听套接字处于阻塞模式或处于超时模式，则由accept()返回的套接字处于阻塞模式;

如果侦听套接字处于非阻塞模式，则由accept()返回的套接字是处于阻塞还是非阻塞模式取决于操作系统。如果您想确保跨平台行为，建议您手动覆盖此设置。

我看过这个[question]：Are socket options inherited across accept() from the listening socket?，我觉得最后的判决仍然是执行定义的。我猜测在平台上比从每个内核读取源代码要容易。

这里它清楚地表明超时选项被继承。但在接受（2）的手册中，没有提到这一点。当我在我的一个盒子（嵌入式Linux盒子）上调试了一些C++代码时，我发现这非常令人震惊。我预计接受的套接字不会继承此选项。

我在哪里可以找到这个问题的明确答案？

Answer 1

如果这是一个C问题，而不是一个Python问题，我不会根据Python文档得出关于SO_RCVTIMEO被accept(2)继承的任何结论。我想你可能误解反正Python的文档，因为它们...

1. 从来没有明确提及SO_RCVTIMEO选项
2. 从来不说的超时值从监听套接字继承的，而是从全局超时值通过setdefaulttimeout()

看着为socketmodule.c的源代码中设置，巨蟒甚至不使用SO_RCVTIMEO套接字选项。而是将超时值存储在其自己的套接字对象的内部表示中，并在调用select(2)和poll(2)时使用它。

我怀疑Python有点奇怪的实现的原因是它设计为在很多平台上运行，其中一些平台不支持SO_RCVTIMEO选项。唯一的参考SO_RCVTIMEO是上线4773 ...

#ifdef SO_RCVTIMEO 
PyModule_AddIntConstant(m, "SO_RCVTIMEO", SO_RCVTIMEO); 
#endif 

...其中它是由预处理器指令所包围，在壳体SO_RCVTIMEO没有在其上它的编译平台上定义的。由accept()方法返回

至于为什么Python文档说...

...插座继承超时...

...那是因为Python的内部实现accept()明确设置新的插座上线732默认的超时值的内部超时值...

s->sock_timeout = defaulttimeout; 

至于原来的问题。 ...

我在哪里可以找到这个问题的明确答案？

...我想你必须通过内核源代码，直到你找到它打猎，但它可能是简单的只是为了让没有什么是继承的假设，并明确覆盖你从任何改变他们的选择默认位于由accept(2)返回的新套接字FD上的父套接字FD上。

Answer 2

BSD套接字API执行此操作。接受的套接字继承监听套接字的所有内容：接收缓冲区大小，超时，KEEPALIVE，close-on-exec。一些更高级别的API（例如Java）会做更多的工作来撤消这个问题，例如读取超时。