Re: PR/57504 CVS commit: src/sys/kern

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/57504; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Taylor R Campbell <riastradh%NetBSD.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: PR/57504 CVS commit: src/sys/kern
Date: Sat, 19 Oct 2024 00:06:59 +0700

     Date:        Fri, 18 Oct 2024 13:42:07 +0000
     From:        Taylor R Campbell <riastradh%NetBSD.org@localhost>
     Message-ID:  <20241018134212.9624084D09%mail.netbsd.org@localhost>
 
   | Some real applications might not keep track of the highest fd they set
   | in the fd_set, and just keep track of the highest fd they have ever
   | allocated seen, or just pass FD_SETSIZE.
 
 They might, but most I have seen (which still use select, and not
 poll) seem to use max_fd+1 -- probably just copying code from place
 to place as is normal.
 
   | Surely we should have an automatic test in atf for this so can verify
   | it has been fixed in pullup too?
 
 Yes, I was looking at doing one of those - waiting for that to happen
 was partly what held up the commit for so long, I've had the code for
 quite a while, & been running it for ages now.   I eventually decided
 that I simply wasn't getting that written any time soon, and decided to
 commit anyway.
 
   | I think a fix for this bug is also worth pulling up to 9 -- basic
   | central functionality like select should be reliable, not spuriously
   | hang in weird circumstances.
 
 Perhaps - it isn't as if we have lots of bug reports about things like
 that happening though do we?   It is also possible that -9 might be, or
 approaching, EOL before I get around do doing any pullups - I think this
 needs a long gestation in HEAD, just because this code is likely to be
 exercised very rarely - if there is something not quite right it might
 take a long time to reveal itself.
 
 kre