patch for threads/76690 - critical - fork hang in child for-lc_r

[Andriy Tkachuk]

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" <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
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