【请教】Linux下用select()监测socket，是不是通常不去监测可写状态的？

[bearzyj2011]

一个简单的client-server程序。
我在server端，用select()函数监测accept()到的client的socket。
这个时候，如果监测该socket的可写状态，发现select()就不阻塞了，因为通常情况下，总是可写的，这就导致select所在的循环几乎处于不断的轮询状态了。

因此，我想请教大家，是不是，这种情况下，通常只监测可读，不监测可写呢？

[bearzyj2011]

引用 1 楼 nevil 的回复:

是的,只监测可读, 因为服务器端总是接收到客户端的连接请求才会做出想应的处理

谢谢，页感谢2楼的回答，我知道可以分开的。 只是，由于我刚开始了解select()这种函数，想知道，既然socket的服务端，通常只是监测可读。那么能否帮忙举一些例子，什么情况下监测可写，会比较有用？？

[qq120848369]

写对于一个异步的服务端架构是非常重要的. 知道写什么时候触发是最重要的, 即网卡只要不满就会触发. 还有一点, 你要知道write写10字节， 但返回值可能!=10，还有可能发生EAGAIN错误（fd非阻塞），这都是因为网卡满了，此时你要把未写出的内容缓存起来，注册写事件, 等写事件触发时把剩余的数据写出去.

[louyong0571]

引用 4 楼 qq120848369 的回复:

写对于一个异步的服务端架构是非常重要的. 知道写什么时候触发是最重要的, 即网卡只要不满就会触发. 还有一点, 你要知道write写10字节， 但返回值可能!=10，还有可能发生EAGAIN错误（fd非阻塞），这都是因为网卡满了，此时你要把未写出的内容缓存起来，注册写事件, 等写事件触发时把剩余的数据写出去.

向版主大人学习！

[nevil]

是的,只监测可读, 因为服务器端总是接收到客户端的连接请求才会做出想应的处理

[louyong0571]

可读可写本来就是可以分开的嘛