阻塞模式下管道上的 select() 返回 EAGAIN
select() 的手册页 没有将 EAGAIN 列为 select( 的可能错误代码) ） 功能。
谁能解释在什么情况下 select() 会产生 EAGAIN 错误？
如果我理解 select_tut 手册页，可以通过向进程发送信号来生成 EAGAIN被阻塞等待阻塞的 select()。这是正确的吗？
由于我在超时的阻塞模式下使用 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 时，我是否应该重复循环？
The man pages for select() do not list EAGAIN as possible error code for the select() function.
Can anyone explain in which cases the select() can produce EAGAIN error?
If I understand select_tut man page, EAGAIN can be produced by sending a signal to the process which is blocked waiting on blocked select(). Is this correct?
Since I am using select() in blocking mode with timeout, like this:
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 ) );
}
should I just repeat the loop when the error number is EAGAIN?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
select()在任何情况下都不会返回EAGAIN。但是，如果被信号中断，它可能会返回 EINTR（这适用于大多数系统调用）。
EAGAIN（或EWOULDBLOCK）可以从read、write、recv返回，发送等select()will not returnEAGAINunder any circumstance.It may, however, return
EINTRif interrupted by a signal (This applies to most system calls).EAGAIN(orEWOULDBLOCK) may be returned fromread,write,recv,send, etc.从技术上讲，EAGAIN 并不是一个错误，而是表明操作在未完成的情况下终止，您应该……呃……再试一次。您可能想要编写逻辑来重试，但不是无限地重试。如果安全的话，他们会在 API 中自己完成。
如果您认为返回这样愚蠢的非错误错误代码有点糟糕的客户端界面设计，那么您不是第一个。事实证明，EAGAIN 作为错误代码在 Unix 中有着悠久而有趣的历史。除其他外，它还催生了广为流传的关于软件设计的文章The Rise of Worse-is -更好。中间有几段解释了为什么 Unix 有时需要返回这个。是的，它确实与 I/O 期间接收中断有关。他们称之为 PC 失败者。
许多人认为这篇文章是敏捷编程的灵感之一。
EAGAIN is technically not an error, but an indication that the operation terminated without completing, and you should...er...try it again. You will probably want to write logic to retry, but not infinitely. If that was safe, they would have done it themselves in the API.
If you are thinking that returing a silly non-error error code like that is kinda bad client interface design, you aren't the first. It turns out EAGAIN as an error code has a long interesting history in Unix. Among other things, it spawned the widely circulated essay on software design The Rise of Worse-is-Better. There's a couple of paragraphs in the middle that explain why Unix needs to return this sometimes. Yes, it does indeed have something to do with receiving interrupts during an I/O. They call it PC loser-ing.
Many credit this essay as one of the inspirations for Agile programming.