為什么會出現(xiàn)select模型？
先看一下下面的這句代碼：
int iResult = recv(s, buffer,1024);
這是用來接收數(shù)據(jù)的，在默認(rèn)的阻塞模式下的套接字里，recv會阻塞在那里，直到套接字連接上有數(shù)據(jù)可讀，把數(shù)據(jù)讀到buffer里后recv函數(shù)才會返回，不然就會一直阻塞在那里。在單線程的程序里出現(xiàn)這種情況會導(dǎo)致主線程（單線程程序里只有一個默認(rèn)的主線程）被阻塞,這樣整個程序被鎖死在這里，如果永 遠沒數(shù)據(jù)發(fā)送過來，那么程序就會被永遠鎖死。這個問題可以用多線程解決，但是在有多個套接字連接的情況下，這不是一個好的選擇，擴展性很差。
再看代碼：
int iResult = ioctlsocket(s, FIOBIO, (unsigned long *)&ul); iResult = recv(s, buffer,1024);
這一次recv的調(diào)用不管套接字連接上有沒有數(shù)據(jù)可以接收都會馬上返回。原因就在于我們用ioctlsocket把套接字設(shè)置為非阻塞模式了。不過你跟蹤一下就會發(fā)現(xiàn)，在沒有數(shù)據(jù)的情況下，recv確實是馬上返回了，但是也返回了一個錯誤：WSAEWOULDBLOCK，意思就是請求的操作沒有成功完成。
看到這里很多人可能會說，那么就重復(fù)調(diào)用recv并檢查返回值，直到成功為止，但是這樣做效率很成問題，開銷太大。
select模型的出現(xiàn)就是為了解決上述問題。
select模型的關(guān)鍵是使用一種有序的方式，對多個套接字進行統(tǒng)一管理與調(diào)度 。
如上所示，用戶首先將需要進行IO操作的socket添加到select中，然后阻塞等待select系統(tǒng)調(diào)用返回。當(dāng)數(shù)據(jù)到達時，socket被激活，select函數(shù)返回。用戶線程正式發(fā)起read請求，讀取數(shù)據(jù)并繼續(xù)執(zhí)行。
從流程上來看，使用select函數(shù)進行IO請求和同步阻塞模型沒有太大的區(qū)別，甚至還多了添加監(jiān)視socket，以及調(diào)用select函數(shù)的額外操作，效率更差。但是，使用select以后最大的優(yōu)勢是用戶可以在一個線程內(nèi)同時處理多個socket的IO請求。用戶可以注冊多個socket，然后不斷地調(diào)用select讀取被激活的socket，即可達到在同一個線程內(nèi)同時處理多個IO請求的目的。而在同步阻塞模型中，必須通過多線程的方式才能達到這個目的。
select流程偽代碼如下：
{
select(socket);
while(1)
{
sockets = select();
for(socket in sockets)
{
if(can_read(socket))
{
&n
