当前位置: 技术问答>linux和unix
【请教】Linux下用select()监测socket，是不是通常不去监测可写状态的？
来源: 互联网 发布时间：2017-03-22
本文导语: 一个简单的client-server程序。 我在server端，用select()函数监测accept()到的client的socket。 这个时候，如果监测该socket的可写状态，发现select()就不阻塞了，因为通常情况下，总是可写的，这就导致select所在的循环几乎处于...
一个简单的client-server程序。
我在server端，用select()函数监测accept()到的client的socket。
这个时候，如果监测该socket的可写状态，发现select()就不阻塞了，因为通常情况下，总是可写的，这就导致select所在的循环几乎处于不断的轮询状态了。
因此，我想请教大家，是不是，这种情况下，通常只监测可读，不监测可写呢？
我在server端，用select()函数监测accept()到的client的socket。
这个时候，如果监测该socket的可写状态，发现select()就不阻塞了，因为通常情况下，总是可写的，这就导致select所在的循环几乎处于不断的轮询状态了。
因此，我想请教大家，是不是，这种情况下，通常只监测可读，不监测可写呢？
|
是的,只监测可读, 因为服务器端总是接收到客户端的连接请求才会做出想应的处理
|
写对于一个异步的服务端架构是非常重要的.
知道写什么时候触发是最重要的, 即网卡只要不满就会触发.
还有一点, 你要知道write写10字节， 但返回值可能!=10，还有可能发生EAGAIN错误（fd非阻塞），这都是因为网卡满了，此时你要把未写出的内容缓存起来，注册写事件, 等写事件触发时把剩余的数据写出去.
知道写什么时候触发是最重要的, 即网卡只要不满就会触发.
还有一点, 你要知道write写10字节， 但返回值可能!=10，还有可能发生EAGAIN错误（fd非阻塞），这都是因为网卡满了，此时你要把未写出的内容缓存起来，注册写事件, 等写事件触发时把剩余的数据写出去.
您可能感兴趣的文章:
本站(WWW.)旨在分享和传播互联网科技相关的资讯和技术，将尽最大努力为读者提供更好的信息聚合和浏览方式。
本站(WWW.)站内文章除注明原创外，均为转载、整理或搜集自网络。欢迎任何形式的转载，转载请注明出处。
本站(WWW.)站内文章除注明原创外，均为转载、整理或搜集自网络。欢迎任何形式的转载，转载请注明出处。