From owner-freebsd-threads@FreeBSD.ORG Fri Mar 4 05:57:21 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7558316A4CE for ; Fri, 4 Mar 2005 05:57:21 +0000 (GMT) Received: from mail.emict.com (brig.emict.com [212.90.172.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3E0243D1F for ; Fri, 4 Mar 2005 05:57:20 +0000 (GMT) (envelope-from andrit@ukr.net) Received: from BORJA (unknown [203.199.120.221]) by mail.emict.com (Postfix) with ESMTP id 7D51134742 for ; Fri, 4 Mar 2005 07:57:17 +0200 (EET) Message-ID: <027801c5207f$082e3ab0$090210ac@BORJA> From: "Andriy Tkachuk" To: References: Date: Fri, 4 Mar 2005 11:27:15 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: patch for threads/76690 - critical - fork hang in child for-lc_r X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 05:57:21 -0000 yes, Daniel, thank you. i've already figured this out, thank to David Xu ) but in libc_r there is not some spinlock_init() i which locks are remembered (as far as i can see) , so i think, that in libc_r it is worth to explicitly unlock the __malloc_lock in child. yours, Andriy. ----- Original Message ----- From: "Daniel Eischen" To: "Andriy Tkachuk" Cc: "David Xu" ; Sent: Thursday, March 03, 2005 20:44 Subject: Re: patch for threads/76690 - critical - fork hang in child for-lc_r > On Thu, 3 Mar 2005, Andriy Tkachuk wrote: > > > > > > Hmm, libc_r and libpthread handle spinlock differently which malloc > > > > > uses to protect itself, some real world benchmarks are better than > > > this. > > > > yes , you right, David. one have to check __isthreaded before > > firing _SPINLOCK. there will be nothing wrong, because > > > > static spinlock_t thread_lock = _SPINLOCK_INITIALIZER; > > > > initialyzed regardless __isthreaded in malloc.c but > > for optimization probably it is worth to add this check. > > Take a look on updated patch. > > > > btw: i don't see the unlock in child in libpthread. there must be two > > unlocks > > I told you in previous mail, _kse_single_thread() calls > _thr_spinlock_init(). The malloc lock is not the only > lock used in libc, so the safe way to make sure libc > is in a clean state after a fork is to reinitialize all > the locks used by libc, not just the malloc lock. libc > really shouldn't try to use any locks unless __isthreaded > is true, so after a fork() it shouldn't really matter > what state the locks are in. > > -- > DE