非阻塞select里read和send的疑问

rubylc_unix

每次读/写之前用select 判断是否可读/写才对，

返回可读才去recv,返回可写时才去send， select 一次才操 ...
windwiny 发表于 2010-12-07 00:41

     应该是第二种阿{:3_189:}

zzyong08

回复 8# larkinboy


    可读，可写，是由tcp协议控制的。比如，对端通告窗口为0，此时就不能写。可读，通常是tcp协议栈中有数据。

zzyong08

回复 5# linuxchyu


    不需要每次读写都select，以读为例，select告诉可读，此时就可以读，但是在不知道有多少数据可读的情况下，是不是要不停的读呢？读到什么时候，才知道没有数据可读呢？读返回错误，并且errno为EAGAIN，表明已经没有数据可读了。此时可以干别的事情了，等再次select告知可读的时候，再读。

ydfgic

说的都对，select只是一个通知作用，你多次读/写，就是赌还有没有数据可读和还有没有空间可写。
如果读写都返回错，再去select等待是可以的。
两种方式都是可行的，完全看程序员的风格了。
我觉得第二种效率更高些，如果数据量大的话

greensnow

自己试一下不就知道了么，你如果是用第一种，在linux上你会发现占用cpu 100%，windows不会。。。
写和读的处理流程大致是一样的。。。

zzyong08

回复 14# larkinboy


    是的，下次还会触发。但我的理解是，为什么不读完，还要select再次触发呢？select并不是效率很高的操作。

FBI888XH

同意楼上。
以前都是用第2种，现在感觉貌似第1种更好。。。