Date: Fri, 4 Mar 2005 11:27:15 +0530 From: "Andriy Tkachuk" <andrit@ukr.net> To: <threads@freebsd.org> Subject: Re: patch for threads/76690 - critical - fork hang in child for-lc_r Message-ID: <027801c5207f$082e3ab0$090210ac@BORJA> References: <Pine.GSO.4.43.0503031008130.2058-201000@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org> To: "Andriy Tkachuk" <andrit@ukr.net> Cc: "David Xu" <davidxu@freebsd.org>; <threads@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?027801c5207f$082e3ab0$090210ac>