Mark Jefferys <[EMAIL PROTECTED]> writes:
> [Summary: Some systems leave the fd_sets alone when select times out.]
> Even if an OS doesn't do this intentionally, it's quite easy to see
> someone forgetting to clear the fd_sets on a timeout by accident, so
> some defensive coding against the problem (explicitly checking for a
> result of 0) may be worthwhile.
>
> Or this may just be a red herring...
I think it isn't relevant. qmail-remote doesn't seem to use select,
or at least it's nowhere in the path where my qmail-remote wedges.
As to different OS behaviour, Solaris 2.6 (and 7) both say:
C Library Functions select(3C)
On failure, the objects pointed to by the readfs, writefs,
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.
whereas SunOS 4.1.4 (my usual 'old bsd system' benchmark) says:
SELECT(2) SYSTEM CALLS SELECT(2)
select() returns a non-negative value on success. A posi-
tive value indicates the number of ready descriptors in the
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.
and I can tell you that I've not seen the problem happen with
qmail-remote on SunOS 4.1.4. Indeed, I think DJB's code (and most
other people's) compensates for both behaviours by setting the
necessary FD's each time anyway.
> N.B. Although someone claimed to have seen a BSD man page reporting
> that it wouldn't clear the fd_sets on a timeout, I was unable to find
See above!
James.
