From owner-freebsd-hackers@FreeBSD.ORG Wed Dec 31 05:47:05 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B7DD16A4CE for ; Wed, 31 Dec 2003 05:47:05 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C39543D3F for ; Wed, 31 Dec 2003 05:47:04 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id hBVDl3iw028936; Wed, 31 Dec 2003 08:47:03 -0500 (EST) Date: Wed, 31 Dec 2003 08:47:03 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Marc Olzheim In-Reply-To: <20031231111642.GA13386@stack.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org Subject: Re: libc_r/uthread/uthread_join.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Dec 2003 13:47:05 -0000 On Wed, 31 Dec 2003, Marc Olzheim wrote: > Hi. > > Is there a reason why in the case that a thread is not done yet, > pthread_join() does not call _thread_kern_sig_undefer() ? > > We have a program where one thread consumes all CPU it can get for > blocks of data. > A status thread is spawned as soon as the main thread starts working on > a new block, printing an 'x % done' message and sleeping for a second in > a loop. When the block is processed, the status thread is > pthread_cancel()d and the main thread does a pthread_join() to wait for > the status thread to exit. Now, when the second block is to be > processed, a new status thread is spawned, but since signals are still > defered and the main thread needs all the cpu it can get, it doesn't get > scheduled in anymore. > > The following fixed the problem in 4-STABLE and it seems to work ok, but > I'm no sure if there was a reason for the omission of the call in that > case... No, it looks like you found a bug. Committed, thanks! -- Dan Eischen