Date: Tue, 22 Jun 2004 16:18:51 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Dan Nelson <dnelson@allantgroup.com> Cc: Chris Stenton <jacs@gnome.co.uk> Subject: Re: pthread - fork - execv problem Message-ID: <Pine.GSO.4.10.10406221614470.17576-100000@pcnet5.pcnet.com> In-Reply-To: <20040622182632.GJ86471@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 22 Jun 2004, Dan Nelson wrote: > 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. Whaa? Adding a function doesn't break ABI, and I don't want to maintain 3 thread libraries. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10406221614470.17576-100000>