From owner-freebsd-threads@FreeBSD.ORG Tue Apr 29 12:14:29 2003 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 794C537B401 for ; Tue, 29 Apr 2003 12:14:29 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A897843FAF for ; Tue, 29 Apr 2003 12:14:28 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h3TJERBg002680; Tue, 29 Apr 2003 15:14:27 -0400 (EDT) Received: from localhost (eischen@localhost)h3TJERhP002677; Tue, 29 Apr 2003 15:14:27 -0400 (EDT) Date: Tue, 29 Apr 2003 15:14:27 -0400 (EDT) From: Daniel Eischen To: Terry Lambert In-Reply-To: <3EAEC9D2.AE47CC0A@mindspring.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? 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, 29 Apr 2003 19:14:29 -0000 On Tue, 29 Apr 2003, Terry Lambert wrote: > Narvi wrote: > > Peter Wemm wrote: > > > Basically he's describing the exact scenario you're concerned about. The > > > last paragraph suggests a better way. > > > > You will then need to make sure something sensible (and not a deadlock) > > happens if fork() gets called at a time when dlopen() / dlclose() is > > running in another thread. > > I think this is a non-sequitur; what's "sensible" in that case? > Should the address space of the fork()'ed process contain the > dlopen()'ed object, or not? > > It seems to me that this situation is a coding error on the part > of the person who did not manually serialize access through a > pthread mutex, so that the address space was controlled over the > fork(), and the resulting process ended up with the state of its > address space known to the programmer. Indeed. POSIX also has this to say about fork(): A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. Fork handlers may be established by means of the pthread_atfork() function in order to maintain application invariants across fork() calls. When the application calls fork() from a signal handler and any of the fork handlers registered by pthread_atfork() calls a function that is not asynch-signal-safe, the behavior is undefined. -- Dan Eischen