Date: Thu, 26 Jul 2001 14:56:08 +0300 (EEST) From: Maxim Sobolev <sobomax@FreeBSD.org> To: dwmalone@maths.tcd.ie (David Malone) Cc: sobomax@FreeBSD.ORG (Maxim Sobolev), current@FreeBSD.ORG, julian@elischer.org (Julian Elischer), stable@FreeBSD.ORG Subject: Re: Strange select(2) misbehaviour when linked with -pthread Message-ID: <200107261156.f6QBu8X79427@vega.vega.com> In-Reply-To: <20010726115931.A93134@walton.maths.tcd.ie> from "David Malone" at Jul 26, 2001 11:59:31 AM
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. I am not sure that the error is what we want to get in this situation. Perhaps more *compatible* solution would be wait indefinitely if timeout is too large. > > 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. Interesting, but this isn't really relevant to my question. I want to know why the program in question behaves difefrently when linked with and without -pthead flag (bug in libc_r?). Also [EINVAL] is not what I'm seeing here, because as you can easily check in my test case tv.tv_sec == 4294976, which is less that 1000000000 - upper limit of our select(2) implementation depicted in PR 18909. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107261156.f6QBu8X79427>