Hi,
> > [Summary: Some systems leave the fd_sets alone when select times out.]
> I think it isn't relevant. qmail-remote doesn't seem to use select,
It does. timeoutread.c:
int timeoutread(t,fd,buf,len) int t; int fd; char *buf; int len;
{
fd_set rfds;
struct timeval tv;
tv.tv_sec = t;
tv.tv_usec = 0;
FD_ZERO(&rfds);
FD_SET(fd,&rfds);
if (select(fd + 1,&rfds,(fd_set *) 0,(fd_set *) 0,&tv) == -1) return -1;
if (FD_ISSET(fd,&rfds)) return read(fd,buf,len);
errno = error_timeout;
return -1;
}
When select returns -1 (error case) everything is fine. When select
returns 0, i.e. in the timeout case, read is called if select has
not cleared the fd bit out of rfds. So if there really exist OS
which do not clear the bits, then qmail will potentially block in
read on those OS.
> As to different OS behaviour, Solaris 2.6 (and 7) both say:
> and errorfds arguments are not modified. If the timeout
> interval expires without the specified condition being true
> for any of the specified file descriptors, the objects
> pointed to by the readfs, writefs, and errorfds arguments
> have all bits set to 0.
On Solaris the above code would work without flaws.
> whereas SunOS 4.1.4 (my usual 'old bsd system' benchmark) says:
> descriptor sets. 0 indicates that the time limit referred
> to by timeout expired. On failure, select() returns -1,
> sets errno to indicate the error, and the descriptor sets
> are not changed.
It doesn't tell explicitly what it does when it returns 0, but as
it's mentioned only in the error case, that the bits are not cleared,
one supposes that in timeout situations they are cleared, and thus
qmail will not have any problems.
claudio
--
Claudio Nieder, Kanalweg 1, CH-8610 Uster, Tel +41 79 357 6743
yahoo messenger: claudionieder aim: claudionieder icq:42315212
mailto:[EMAIL PROTECTED] http://www.claudio.ch
