socket fd must less than 102400,otherwise will crash? about libco HOT 6 OPEN

不明白你的重分配为什么会有延迟，Linux里面有的机制就是想重用fd，比如dup()调用来重定向std和其他描述符。
Linux的pid_t虽然是int类型，但是最大也会有限制的，一般是32k，请参见
/proc/sys/kernel/pid_max

当然他们这么做，但又没有在文档中说明，这点是他们有所疏漏。

from libco.

为什么可以不处理alloc_by_fd返回NULL的情况呢，难道是默认不可能发生FD超过102400的情况？为什么呢？

from libco.

这个感觉默认不会出现太大的问题，因为现在Linux操作系统默认每个进程打开的fd数目是1024，作为服务器通常会改为64k，不过加一个检测更好。

from libco.

不是很了解OS对FD的分配机制，OS会重用已经使用过的FD，但是可能有一个时间延迟在里面的，应该是需要做检测的，假如服务器的是64K，但是libco里面的是100K，如果OS来不及重用的话，那很可能FD就大于100K了，如果服务器的是100K，那么crash的概率就更大了。libco还有其他地方是直接用进程ID作为10K长度数组的下标的，这个感觉有不太严谨吧，难道每个OS都会保证PID小于10K？

from libco.

延迟重用FD是我的猜测，用“肯定“”这个词是不严谨，改用“”可能“”吧，如果linux是尽快重用被释放的FD的话在应用层可能就是造成比较难以察觉的错误。比如A线程正在使用fd_a,突然由于BUG或者意外被B线程关闭了fd_a,并立即新创建了一个fd,如果新创建的fd立即重用被释放的fd_a,那么A线程是无法觉察到这个fd_a其实是一个全新的FD的。基于此，所以我就猜测这个FD重用可能会有一个时间上的延迟。

from libco.

你好，是这样的，我们内部使用的g_rpchook_socket_fd配置值都会比较大，保证大于等于操作系统的配置。
开源的时候，我们为了兼顾不同的机器内存大小问题，所以设置了一个比较保守的值，具体开发的时候可以先调整这个大小以规避问题。
后面我们再整合下这个值的动态配置方法，谢谢：）

from libco.