C linux选择性能场景
我编写了一个简单的tcp服务器应用程序，其中用于读取的fd_集包括连接套接字描述符。服务器应用程序只要在收到消息时发送ACK即可。客户端应用程序仅在从服务器收到ACK后发送下一条消息C linux选择性能场景,c,linux,tcp,C,Linux,Tcp,我编写了一个简单的tcp服务器应用程序，其中用于读取的fd_集包括连接套接字描述符。服务器应用程序只要在收到消息时发送ACK即可。客户端应用程序仅在从服务器收到ACK后发送下一条消息 // timeval == NULL select(maxfd, &read_set, NULL, NULL, NULL) 当我这样做时，性能大约是3K消息/秒。发送ack和从客户端接收响应之间的延迟为0.3ms // tm.tv_sec=0 and tm.tv_usec=0 select(maxfd,
// timeval == NULL
select(maxfd, &read_set, NULL, NULL, NULL)
// tm.tv_sec=0 and tm.tv_usec=0
select(maxfd, &read_set, NULL, NULL, tm)
在后一种情况下，select将成为轮询。有人能解释一下为什么后一种情况比第一种情况好得多吗 选择（2）的手册页显示 超时是之前经过的时间量的上限 select（）返回。如果timeval结构的两个字段都为零， 然后select（）立即返回。（这对于轮询很有用。）如果 超时为空（无超时），select（）可以无限期阻止
重点是我的。如果您担心延迟，您应该查看。可能的答案 当超时为零时，如果没有可用数据，select（）调用将立即返回。这使您可以忙着等待轮询套接字，在数据到达之前主动消耗CPU周期 当超时为NULL时，如果没有数据，进程将处于等待可中断状态，等待数据可用。这将导致至少两个上下文切换的惩罚，一个离开流程，另一个在数据可用时返回流程。这样做的好处是，您的进程放弃了CPU，并允许其他进程运行
这就像比较。自旋锁“自旋”CPU等待条件，而信号量产生CPU。自旋锁的性能更高，但占用了CPU，因此只能用于非常非常短的等待。信号量与其他进程的协作性更强，但由于额外的上下文切换，它们会产生明显的开销。这不会回答您的问题，但如果您确实希望获得良好的性能，并且如果接收到的消息率相当高，您可以尝试：
- 用O_非块打开
- 首先尝试阅读
- 如果读取失败，错误代码为EAGAIN或EWOLDBLOCK，请使用timeval==NULL进行选择
- 过程数据
read\u set