From owner-freebsd-threads@FreeBSD.ORG Tue Apr 29 12:29:31 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 CB4EA37B401 for ; Tue, 29 Apr 2003 12:29:31 -0700 (PDT) Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4424243F3F for ; Tue, 29 Apr 2003 12:29:31 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0394.cvx22-bradley.dialup.earthlink.net ([209.179.199.139] helo=mindspring.com) by heron.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19Aan3-0006Ah-00; Tue, 29 Apr 2003 12:29:22 -0700 Message-ID: <3EAED240.9A2C0534@mindspring.com> Date: Tue, 29 Apr 2003 12:28:00 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Narvi References: <20030429202837.L40030-100000@haldjas.folklore.ee> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a48f4d056159cc70ff3bf6ed99055ba00f3ca473d225a0f487350badd9bab72f9c350badd9bab72f9c 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 19:29:32 -0000 Narvi wrote: > On Tue, 29 Apr 2003, Daniel Eischen wrote: > > Yes, this is true, but no threads library that we have currently > > tracks internal locks so they can be reinitialized after a fork. > > It is possible that a fork() will leave things in the locked > > state. But even if they were locked, you'd only see a problem > > if the forked program again became threaded. > > No, you would see the problem as soon as you tried to use a function that > used a locked structure, depending on how the dynamic linker did thinks > this might include any fiunction, including exec* - threads + forking > gives you really fascinating problems. How do you know that say malloc > state was consistent at the moment you forked? You really need > per-subsystem cleanups so that you won't occasionaly fail miserably. Its > not really the threads lib that can / should track locks, unless it comes > with its own copy of the subsystems. Exactly. It's a programming error. You don't know if they wanted the dlopen()'ed object in scope in the child process after the fork, or not, so if you have a dlopen()/fork() race, you can never know if it will get added (or removed, if we include dlclose() races) before or after the actual fork() has taken place. It's bogus for the programmer to use these types of interfaces without providing their own serialization so that they know for certain what the state of the mapped object is, after the fork(). -- Terry