From owner-freebsd-hackers Tue Aug 13 1:31:52 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E0A037B400; Tue, 13 Aug 2002 01:31:40 -0700 (PDT) Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB97643E42; Tue, 13 Aug 2002 01:31:39 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0012.cvx21-bradley.dialup.earthlink.net ([209.179.192.12] helo=mindspring.com) by avocet.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17eX5R-0006a4-00; Tue, 13 Aug 2002 01:31:33 -0700 Message-ID: <3D58C359.A5F7B1AA@mindspring.com> Date: Tue, 13 Aug 2002 01:29:13 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Maxim Sobolev Cc: hackers@FreeBSD.ORG, audit@FreeBSD.ORG, Alexander Litvin , Andriy Gapon Subject: Re: Thread-safe resolver [patches for review] References: <3D578A99.F0821712@FreeBSD.org> <3D5792CD.497C80F0@mindspring.com> <3D57A9D4.DAA043EF@FreeBSD.org> <3D57CF6D.2982CE8@mindspring.com> <3D58BFE8.9281433@FreeBSD.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Maxim Sobolev wrote: > This scenario doesn't look as a legitimate way to do things for me. > Let's inspect what will happen when you are unloading a PIC module, > which has one or more threads running. There are two possibilities: > either thread scheduler (libc_r) was linked with the program itself > and therefore loaded with it, or it was linked with PIC module and > loaded along with that module. In the first case, after you have > dlclose'd the PIC module, dynamic linker will unmap module's code from > memory, but the thread scheduler will remain running and on the next > attempt to pass control to the thread in your PIC module will probably > get SIGBUS due to the fact that code is no longer mapped. In the > second case, you'll unload module along with thread scheduler, but > thread-scheduling signals setup will remain in place, so that shortly > you will get the same SIGBUS, when the kernel will be trying to > delivery signal to no longer mapper region. Unless you have a single exported API from the .so that takes a single request, and does simultaneous lookups. The result will be two inactive threads hanging on a condition variable which will never come true, because the function which makes it true in order to trigger the parallel lookup has been unloaded. Basically, a sleep is a sleep, and it doesn't matter if the code that caused it is there any more or not, if you never get a wakeup. To use an analogy, it doesn't matter if the SIGHUP handler will cause a core dump, if you never get a SIGHUP, does it? > In either case, you will get the problem much more serious than memory > leak. Assuming, incorrectly, that you are talking to the threads directly, rather than to a proxy function. The calling program need not be threaded or support threads. > > The assumption (which is potentially wrong) is that the program > > will correctly shut down all its threads, when in fact it was a > > module not under the programs control that created and used the > > threads. > > I do not quite agree. In such case, the module should probably have > destructor function, either placed into the fini section, or to be > explicitly called by the program before dlclose(). Uh, that's exactly the argument I was making: use a .fini section to clean up the per thread memory allocations. 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message