2010-03-15 68 views
4

我有一個應用程序處理與阻塞呼叫的網絡通信。每個線程管理一個連接。我在讀取和寫入操作上添加了一個超時,在讀取或寫入套接字之前使用select。Select()Ok是否實現單套接字讀/寫超時?

在處理大量套接字時,Select被認爲是低效的。但是,就性能而言,它可以與單個套接字一起使用,還是有更有效的方法在單個套接字調用上添加超時支持?選擇的好處是便攜。

回答

4

是的,這是沒有問題的,你想要一些超時機制不是壞行爲的計算機等

注意泄漏資源具有大量線程的是它比有大量選擇交易效率越低的插座。

+0

Thanx。我打算使用libev來處理多個併發的通信通道。在這個階段,我只考慮一個線程訪問一個套接字。 – chmike 2010-03-15 15:49:57

2

如果您認爲uthink select對於大量套接字而言效率低下,請嘗試每個sockt使用一個線程處理大量套接字。你正處於一個痛苦的世界。就像你會遇到擴展到1000個線程的問題。

我在過去所做的那樣是:

  • 組插座,X(512,1024)的羣體。
  • 沿這些組運行一個或兩個線程並選擇() - 然後將具有新數據的套接字交給隊列。
  • 有一些工作線程使用新數據處理這些套接字。多少取決於我多麼需要最大程度的發揮CPU)

這樣,我不ahve超級尤伯杯選擇()與項目噸,我也不要浪費在線程的內存可笑amountf(提示:每個線程都需要它自己的堆棧,只有2MB,對於1000個插槽來說就是2GB - 談論效率低下),並浪費CPU的時間去做無用的上下文切換。

0

線程/ select的問題在於是否要避免客戶端互相阻塞。如果這不是問題,那麼單線程工作。如果是,請選擇適當的線程方案(每個連接1個線程,每個連接的工作線程,每個請求的工作線程...)。

當每個連接使用1個線程時,每個讀/寫的選擇是一個體面的解決方案,但一般來說,最好使用非阻塞套接字與select結合使用,以避免在只有一部分的預期消息到達,然後在寫入後進行選擇。