From owner-freebsd-current Thu Jul 26 4:56:57 2001 Delivered-To: freebsd-current@freebsd.org Received: from vega.vega.com (dialup6-52.iptelecom.net.ua [212.9.227.116]) by hub.freebsd.org (Postfix) with ESMTP id E3E8437B405; Thu, 26 Jul 2001 04:56:42 -0700 (PDT) (envelope-from max@vega.com) Received: (from max@localhost) by vega.vega.com (8.11.4/8.11.3) id f6QBu8X79427; Thu, 26 Jul 2001 14:56:08 +0300 (EEST) (envelope-from sobomax@FreeBSD.org) From: Maxim Sobolev Message-Id: <200107261156.f6QBu8X79427@vega.vega.com> Subject: Re: Strange select(2) misbehaviour when linked with -pthread To: dwmalone@maths.tcd.ie (David Malone) Date: Thu, 26 Jul 2001 14:56:08 +0300 (EEST) Cc: sobomax@FreeBSD.ORG (Maxim Sobolev), current@FreeBSD.ORG, julian@elischer.org (Julian Elischer), stable@FreeBSD.ORG In-Reply-To: <20010726115931.A93134@walton.maths.tcd.ie> from "David Malone" at Jul 26, 2001 11:59:31 AM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > 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