httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Finch <...@dotat.at>
Subject Re: checking for EWOULDBLOCK/EAGAIN *inside* APR
Date Mon, 10 Apr 2000 12:30:38 GMT
Dave Jones <JONESD@er6s1.eng.ohio-state.edu> wrote:
>
>I'm missing something too.  EAGAIN and EWOULDBLOCK to me mean different things:
>
>   EAGAIN       Means a blocking system call was aborted because the process 
>                caught a signal or some other failure.  You are supposed
>                to decide if you still want to make the request (i.e. the
>                signal wasn't requesting an abort) and try it again.
>
>   EWOULDBLOCK  Means a non-blocking system call failed because of inadequate
>                resources.  Wait for the resource to because available
>                and then try again.
>
>At some point, someone noticed that system calls can return one or the
>other, but not both, so they equated them to the same value.  They are still
>logically differently errors, with different recovery actions, so code that 
>is doing I/O to a non-blocking socket should check for EWOULDBLOCK and not 
>EAGAIN.

Your description of the meaning is not right. Signals cause EINTR, not
EAGAIN. For an example of where EAGAIN has the definition you
attribute to EWOULDBLOCK see fork(2) or fcntl(2). POSIX decided to use
EAGAIN where BSD uses EWOULDBLOCK so it's better to always use EAGAIN.
(Unlike read(2) and write(2), flock(2) wasn't POSIXized so still uses
EWOULDBLOCK.)

Tony.
-- 
f.a.n.finch    fanf@demon.net    dot@dotat.at
294 dancing spit on the griddle

Mime
View raw message