Date: Thu, 26 Jul 2001 11:59:31 +0100 From: David Malone <dwmalone@maths.tcd.ie> To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: current@FreeBSD.org, Julian Elischer <julian@elischer.org>, stable@FreeBSD.org Subject: Re: Strange select(2) misbehaviour when linked with -pthread Message-ID: <20010726115931.A93134@walton.maths.tcd.ie> In-Reply-To: <3B5EA985.458B39B7@FreeBSD.org>; from sobomax@FreeBSD.org on Wed, Jul 25, 2001 at 02:12:06PM %2B0300 References: <3B5EA985.458B39B7@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 25, 2001 at 02:12:06PM +0300, Maxim Sobolev wrote: > I found that the attached small program behaves very strangely when > linked with -pthread - it chews 100% CPU cycles while waiting in > select(2). This misbehaviour observed both on 5-CURRENT and 4-STABLE > systems. *weird* The timeout is too long. At the moment there is an arbitary limit on how long you can wait 'cos the kernel incorrectly uses itimerfix on the timeout passed to select. I have patches to improve the situation and I was waiting for Bruce to review them, but I've been using them at home for ages, so maybe I should just commit them. The patches only have select return an error if the timeout is too long to be implimented using the kernel's counters. > P.S. And yes, I know that I ought to use NULL instead of &tv when I > want to wait indefinitely in select(2), but it is how some programs > work. Or don't work as the case may be ;-) Posix doesn't actually require select to be able to deal with large wait times (I think 31 days was the figure I found in the SUSv2 spec). Have a look at: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=18909 for more details. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010726115931.A93134>