套接字处于阻塞模式
你认为使用带有阻塞套接字的select()是一个好主意还是更好地使用超时SO_SNDTIMEO/SO_RCVTIMEO
（我在Linux下，套接字设置在SOCK_STREAM上）
优点第一个解决方案是它可以与任何类型的套接字一起使用（阻塞和/或非阻塞状态）
Do you think using select() with blocking socket is a good idea or better use timeout SO_SNDTIMEO/SO_RCVTIMEO
(I'm under Linux, socket is sets on SOCK_STREAM)
The advantage with the first solution is that it could work with any type of sockets (blocking and/or non-blocking state)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
假设您想用
read()/write()/send()/etc 来跟踪select()..当它返回就绪条件时，如果您的文件描述符处于阻塞模式，您当然必须非常小心。对于读取，您必须确保在收到读取就绪指示后只读取一次，因为第二次可能会阻塞。对于写入来说，情况可能更糟：我想可能存在一些模糊的条件，在这种情况下，select()报告套接字已准备好，但发生了一些事情，并且在您write()<时它不再准备就绪。 /代码> 到它。即使最后一个假设过于悲观，我也会认为这个解决方案是不可维护的并且是不好的做法。考虑到使用 fcntl() 动态地将文件描述符从阻塞切换到非阻塞并返回并不困难，您是否如此担心与阻塞套接字兼容？只需将它们更改为非阻塞即可。
Assuming you want to followup
select()withread()/write()/send()/etc.. when it returns ready conditions, you certainly have to be really careful if your file descriptors are in blocking mode. For reads, you have to make really sure you only read once after you get a read-ready indication because the second one might block. For writes it's probably worse: I imagine there could be obscure conditions under which the socket is reported ready byselect()but something happens and it's no longer ready by the time youwrite()to it. Even if this last supposition is too pessimistic, I would consider this solution to be unmaintainable and bad practice.Considering it's not difficult to switch a file descriptor dynamically from blocking to nonblocking and back using
fcntl(), you are you so concerned about being compatible with blocking sockets? Just change them to nonblocking.