Mark Delany <[EMAIL PROTECTED]> writes:
> Sorry to say - it never got resolved. I believe it's an OS bug as I've
> never seen it on other systems that I've run qmail on and the code looks
> completely correct.
> If you look at timeoutread.c you'll see that the code has issued the
> read() as a consequence of the previous select() call indicating that
> the fd can be read.
The last time we analyzed this and tracked it down in INN, I added the
following comment to the INN source code:
i = read(cp->fd, &bp->Data[bp->Used], maxbyte-1);
if (i < 0) {
/* Solaris (at least 2.4 through 2.6) will occasionally return
EAGAIN in response to a read even if the file descriptor already
selected true for reading, apparently due to some internal
resource exhaustion. In that case, return -2, which will drop
back out to the main loop and go on to the next file descriptor,
as if the descriptor never selected true. This check will
probably never trigger on platforms other than Solaris. */
if (errno == EAGAIN) {
return -2;
}
INN uses fully non-blocking sockets, so the read returns EAGAIN
immediately. If the socket weren't set nonblocking, I'm not sure if the
read would block or not; it might.
--
Russ Allbery ([EMAIL PROTECTED]) <URL:http://www.eyrie.org/~eagle/>
