From owner-freebsd-stable Fri Jul 27 6:55:38 2001 Delivered-To: freebsd-stable@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id F09F337B406; Fri, 27 Jul 2001 06:55:28 -0700 (PDT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 27 Jul 2001 14:55:28 +0100 (BST) Date: Fri, 27 Jul 2001 14:55:27 +0100 From: David Malone To: Maxim Sobolev Cc: current@FreeBSD.org, julian@elischer.org, stable@FreeBSD.org, deischen@FreeBSD.org Subject: Re: Strange select(2) misbehaviour when linked with -pthread Message-ID: <20010727145527.A37786@walton.maths.tcd.ie> References: <20010726115931.A93134@walton.maths.tcd.ie> <200107261156.f6QBu8X79427@vega.vega.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107261156.f6QBu8X79427@vega.vega.com>; from sobomax@FreeBSD.org on Thu, Jul 26, 2001 at 02:56:08PM +0300 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Jul 26, 2001 at 02:56:08PM +0300, Maxim Sobolev wrote: > 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. I guess this could cause problems for programs that use select to time stuff accurately? > 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. I think I've found out what is wrong. All timing with the pthreads library is actually implimented using poll, which takes a timeout as an int in ms. The timeout you begin with is 2^32-1 as an unsigned int and gets converted to a timeval and then a timespec and then back to -1 as an int. Netgative timeouts are converted to zero and so the code ends up spinning. I guess what the code should do is set a non-zero timeout if this sort of problem crops up. I think it will just end up trying the timeout again when the short timer expires. Try the patch below. I chose 31 seconds as the timeout 'cos 31 seconds will always be representable in ms in an int. David. --- /tmp/dwmalone/uthread_kern.c Fri Jul 27 14:44:52 2001 +++ uthread/uthread_kern.c Fri Jul 27 14:49:10 2001 @@ -699,6 +699,9 @@ * Calculate the time left for the next thread to * timeout: */ + if (pthread->wakeup_time.tv_sec - ts.tv_sec > 31) + timeout_ms = 31 * 1000; + else timeout_ms = ((pthread->wakeup_time.tv_sec - ts.tv_sec) * 1000) + ((pthread->wakeup_time.tv_nsec - ts.tv_nsec) / 1000000); To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message