From owner-freebsd-threads@FreeBSD.ORG Tue Apr 29 11:53:36 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 CD12F37B404; Tue, 29 Apr 2003 11:53:36 -0700 (PDT) Received: from puffin.mail.pas.earthlink.net (puffin.mail.pas.earthlink.net [207.217.120.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id C95B543FD7; Tue, 29 Apr 2003 11:53:35 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0394.cvx22-bradley.dialup.earthlink.net ([209.179.199.139] helo=mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19AaEI-0005NN-00; Tue, 29 Apr 2003 11:53:27 -0700 Message-ID: <3EAEC9D2.AE47CC0A@mindspring.com> Date: Tue, 29 Apr 2003 11:52:02 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Narvi References: <20030429145307.L40030-100000@haldjas.folklore.ee> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a43096268d63a3255db8e68c054dc5bf57a7ce0e8f8d31aa3f350badd9bab72f9c350badd9bab72f9c cc: jdp@freebsd.org cc: threads@freebsd.org cc: Daniel Eischen 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 18:53:37 -0000 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. I think it's OK to fail pretty spectacularly if a programmer is silly enough to cause this situation to occur in the first place; the idea that the protection against this type of coding error should be intrinsic to the library ignores the order-of-operation issue, which can only be resolved by the computer reading the programmers mind to determine the intent of the programmer. This reminds me of the kooks who pop up every once in a while and demand that libc functions not segfault when passed NULL pointers, and that all arguments be checked by the libc functions before they are used... an OS with training wheels, so to speak. -- Terry