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

[Daniel Eischen]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libc_r-76690pr.patch2
Type: application/octet-stream
Size: 901 bytes
Desc: 
Url : http://lists.freebsd.org/pipermail/freebsd-threads/attachments/20050303/d041483b/libc_r-76690pr.obj
-------------- next part --------------
_______________________________________________
freebsd-threads at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-threads
To unsubscribe, send any mail to "freebsd-threads-unsubscribe at freebsd.org"