Linux套接字文件描述符通常适用于散列

我正在编写一个Linux多用户服务器,并且每个接受的连接都会返回一个包含该连接的套接字文件描述符的int 。 我也有一个对应于每个连接的UserConnection对象。 我正在使用散列表(C ++ STL unordered_map<int, UserConnection> )来存储套接字文件描述符(键)和UserConnection对象(值)的键值对。

将套接字文件描述符作为关键字放在哈希表中是否安全? Linux的套接字号码分配有没有任何模式可能不适用于散列函数?

open(2)的手册页明确指出,最低的未使用的文件描述符被分配给新的文件描述符:

成功调用返回的文件描述符将是当前未打开的最低编号的文件描述符。

类似的措词似乎从socket(2)丢失,但我认为这是一个相当安全的假设 – 这也适用于套接字。

然后,创建套接字将导致单调增加文件描述符,为新的套接字,这将在第一次机会重用。 因此,这是散列的理想用例。