Date: Wed, 2 Mar 2005 10:48:08 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Andriy Tkachuk <andrit@ukr.net> Cc: threads@freebsd.org Subject: Re: patch for threads/76690 - critical - fork hang in child for -lc_r Message-ID: <Pine.GSO.4.43.0503021042310.26125-100000@sea.ntplx.net> In-Reply-To: <000e01c51f37$fb3dc980$090210ac@BORJA>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2 Mar 2005, Andriy Tkachuk wrote: > Hi folks. > > I spent some time on the problem in $subj and found some > solution that seems to be working but i'm not sure about it's > architectural correctness because libc was changed little bit ;) This is already fixed in libpthread in both -current and -stable. Your patch also pollutes the application namespace with a global symbol thread_lock -- there is already a symbol in malloc.c that is there just for this purpose (__malloc_lock). See how libpthread uses __malloc_lock and reinitializes the spinlocks in thr_kern.c (_kse_single_thread()). Is there a reason you are still using libc_r? -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0503021042310.26125-100000>