Date: Tue, 22 Jun 2004 13:26:33 -0500 From: Dan Nelson <dnelson@allantgroup.com> To: Chris Stenton <jacs@gnome.co.uk> Cc: hackers@freebsd.org Subject: Re: pthread - fork - execv problem Message-ID: <20040622182632.GJ86471@dan.emsphone.com> In-Reply-To: <20040622154056.GA8733@diogenis.ceid.upatras.gr> References: <011f01c4578b$923d7b70$4b7ba8c0@gnome.co.uk> <20040622145632.GF86471@dan.emsphone.com> <20040622154056.GA8733@diogenis.ceid.upatras.gr>
next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Jun 22), Nikos Ntarmos said: > On Tue, Jun 22, 2004 at 09:56:33AM -0500, Dan Nelson wrote: > > It may be an application bug. After a fork both processes are > > independant. The child should not be able to affect the parent > > like this, unless the parent does something like holding a mutex > > used by all the threads and calling wait(). > > ... or the child holding a mutex before the fork(2) syscall. FWIW the > Linux info for libc and the NetBSD and Solaris man pages mention > pthread_atfork(3), used to install handlers to take care of such > cases. FreeBSD seems to not know of any such function, so chances are > that fork()'ing from inside a posix thread is not supported (?). It's definitely a possibility. libpthread in -current does support pthread_atfork, and I have a patch (below) that adds the same functionality to libc_r and libthr that I need to send-pr. Pointy hat to the original committer for breaking ABI compatibility. http://dan.allantgroup.com/FreeBSD/ -- Dan Nelson dnelson@allantgroup.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040622182632.GJ86471>