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