From owner-freebsd-threads@FreeBSD.ORG Tue Jun 22 20:19:11 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6294416A4CE; Tue, 22 Jun 2004 20:19:11 +0000 (GMT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E204F43D49; Tue, 22 Jun 2004 20:19:10 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i5MKIpon018521; Tue, 22 Jun 2004 16:18:51 -0400 (EDT) Date: Tue, 22 Jun 2004 16:18:51 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Dan Nelson In-Reply-To: <20040622182632.GJ86471@dan.emsphone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org cc: threads@freebsd.org cc: Chris Stenton Subject: Re: pthread - fork - execv problem X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 20:19:11 -0000 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