處於阻塞模式的管道上的select（）返回EAGAIN

Question

select（）的手冊頁沒有列出EAGAIN作為select（）函數的可能錯誤代碼。

誰能解釋在哪種情況下select（）會產生EAGAIN錯誤？

如果我了解select_tut手冊頁 ，則可以通過向被阻塞的進程發送信號，等待阻塞的select（）來產生EAGAIN。 這個對嗎？

由於我在具有超時的阻止模式下使用select（），如下所示：

bool selectRepeat = true;
int res = 0;
timeval  selectTimeout( timeout );
while ( true == selectRepeat )
{
  res = ::select( fd.Get() + 1,
                  NULL,
                  &writeFdSet,
                  NULL,
                  &selectTimeout );
  selectRepeat = ( ( -1 == res ) && ( EINTR == errno ) );
}

錯誤號為EAGAIN時，我應該重復循環嗎？

Answer 1

在任何情況下， select()都不會返回EAGAIN 。 但是，如果被信號中斷，它可能會返回EINTR （這適用於大多數系統調用）。

EAGAIN （或EWOULDBLOCK ）可以從read ， write ， recv ， send等返回。

Answer 2

從技術上講，EAGAIN並不是錯誤，而是表示操作未完成而終止，您應該...再嘗試一次。 您可能需要編寫邏輯來重試，但不是無限的。 如果那是安全的，他們將自己在API中完成。

如果您認為像這樣愚蠢的非錯誤錯誤代碼是很糟糕的客戶端界面設計，那么您不是第一個。 事實證明，EAGAIN是一個錯誤代碼，在Unix中歷史悠久。 除其他事項外，它催生了關於軟件設計《 The Worse-is-Better的崛起》的廣泛散文。 中間有幾個段落解釋了為什么Unix有時需要返回此內容。 是的，的確與I / O期間接收中斷有關。 他們稱其為PC失敗者。

許多人認為這篇文章是敏捷編程的靈感之一。