From owner-freebsd-threads@FreeBSD.ORG  Thu Mar  3 10:47:00 2005
Return-Path: <owner-freebsd-threads@FreeBSD.ORG>
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 24A8D16A4CE
	for <threads@freebsd.org>; Thu,  3 Mar 2005 10:47:00 +0000 (GMT)
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 049DB43D2F; Thu,  3 Mar 2005 10:47:00 +0000 (GMT)
	(envelope-from davidxu@freebsd.org)
Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1])
	by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j23AkuU4057535;
	Thu, 3 Mar 2005 10:46:59 GMT
	(envelope-from davidxu@freebsd.org)
Message-ID: <4226EB21.9090401@freebsd.org>
Date: Thu, 03 Mar 2005 18:46:57 +0800
From: David Xu <davidxu@freebsd.org>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US;
	rv:1.7.2) Gecko/20041004
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Andriy Tkachuk <andrit@ukr.net>
References: <012901c51fd3$131e23b0$090210ac@BORJA>
In-Reply-To: <012901c51fd3$131e23b0$090210ac@BORJA>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
cc: threads@freebsd.org
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 <freebsd-threads.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>,
	<mailto:freebsd-threads-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-threads>
List-Post: <mailto:freebsd-threads@freebsd.org>
List-Help: <mailto:freebsd-threads-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-threads>,
	<mailto:freebsd-threads-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Mar 2005 10:47:00 -0000

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
>- in child & in parent, doesn't it? :
>
># grep __malloc_lock -r libpthread
>libpthread/thread/thr_fork.c:           _spinlock(__malloc_lock);
>libpthread/thread/thr_fork.c:           if ((_kse_isthreaded() != 0) &&
>(__malloc_lock != NULL)) {
>libpthread/thread/thr_fork.c:                   _spinunlock(__malloc_lock);
>#
>  
>
in libpthread, all spinlocks hold by current thread are reinitialized by
_thr_spinlock_init()  in thr_spinlock.c, so in child process, it is not 
needed to
unlocked it again. After a fork(),  in child process, current thread is 
a fresh
thread which should never hold any lock.

David Xu