Date: Tue, 25 Oct 2005 08:52:16 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Sven Berkvens-Matthijsse <sven@ilse.net> Cc: Marc Olzheim <marcolz@stack.nl>, Marc Olzheim <marcolz@ilse.net>, David Xu <davidxu@freebsd.org>, freebsd-threads@freebsd.org Subject: Re: threads/76690: fork hang in child for (-lc_r & -lthr) Message-ID: <Pine.GSO.4.43.0510250847410.22425-100000@sea.ntplx.net> In-Reply-To: <20051025071619.GS22568@ilse.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 25 Oct 2005, Sven Berkvens-Matthijsse wrote: > > > But then the free() in the child process may be using an unstable > > > state of the malloc system (because if you don't acquire the lock > > > before the fork(), malloc() may be busy in the middle of the > > > fork()). > > > > I don't think that can happen because libc_r will not switch out a > > thread that is in a critical region (and libc locks are critical > > regions) until it leaves the region. > > What code leads you to that conclusion? All the malloc functions I had thought that spinlocks and internal mutexes (_pthread_mutex_lock() called from libc) would mark critical regions. That was the intent, but it doesn't seem to be implemented that way in libc_r. It _is_ implemented that way in libpthread. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0510250847410.22425-100000>