Date: Thu, 18 Feb 1999 01:30:43 -0700 From: Warner Losh <imp@village.org> To: Stephen McKay <syssgm@detir.qld.gov.au>, freebsd-hackers@FreeBSD.ORG Subject: Re: select(2) proposed change Message-ID: <199902180830.BAA66657@harmony.village.org> In-Reply-To: Your message of "Thu, 18 Feb 1999 01:15:43 MST." <199902180815.BAA66534@harmony.village.org> References: <199902180815.BAA66534@harmony.village.org> <199902180742.RAA27123@nymph.detir.qld.gov.au> <199902180511.WAA65110@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199902180815.BAA66534@harmony.village.org> Warner Losh writes: : I've been there with the Linux experiment back in the 0.99p14 : timeframe of Linux. I cannot tell you the number of bogus programs : out there that caused 100% cpu usage. If I recall my history : correctly, a new system call was added, __bsd_select, which didn't : change the timeout parameter. select was #defined to this, unless you : did something to prevent it. I think at first this was in the -lbsd : library that merged into libc over time and is now the default. I'll : check with my Linux running friends to verify things. I've looked at the kernel more closely. The is sys_select which will, unless STICKY_TIMEOUTS is set, update the timeout. I don't have the sources to libc handy, but I do know that there are two flavors of select available. I'm unable to verify which one is actually the default. STICKY_TIMEOUTS is set when the personality is anything except PER_LINUX. Well, it isn't set for PER_BSD, but that is wrong since *NO* BSD based OS that I've ever seen has touched timeout. It is late, and I don't have the energy to look on the net to find the libc sources to check. The only Linux machine that i have access to is one that is running 1.1.<bigint>, which isn't exactly a current machine. Anyway, the point does remain that Linux is the *ONLY* os to *EVER* writeback timeout. And it takes no care, as far as I can tell, to ensure that the timeout value is used quickly enough in the general case for it not to suffer from race conditions which limit its usefulness. Finally, I do agree that new code should not assume that timeout is const. Just don't change FreeBSD to stomp on this value. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902180830.BAA66657>