patch for threads/76690 - critical - fork hang in child for-lc_r
andrit at ukr.net
Fri Mar 4 05:57:21 GMT 2005
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.
----- Original Message -----
From: "Daniel Eischen" <deischen at freebsd.org>
To: "Andriy Tkachuk" <andrit at ukr.net>
Cc: "David Xu" <davidxu at freebsd.org>; <threads at freebsd.org>
Sent: Thursday, March 03, 2005 20:44
Subject: Re: patch for threads/76690 - critical - fork hang in child
> On Thu, 3 Mar 2005, Andriy Tkachuk wrote:
> > > > > Hmm, libc_r and libpthread handle spinlock differently which
> > > > > uses to protect itself, some real world benchmarks are better
> > > 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.
More information about the freebsd-threads