Date: Tue, 13 Aug 2002 01:29:13 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: hackers@FreeBSD.ORG, audit@FreeBSD.ORG, Alexander Litvin <archer@whichever.org>, Andriy Gapon <agapon@excite.com> Subject: Re: Thread-safe resolver [patches for review] Message-ID: <3D58C359.A5F7B1AA@mindspring.com> References: <3D578A99.F0821712@FreeBSD.org> <3D5792CD.497C80F0@mindspring.com> <3D57A9D4.DAA043EF@FreeBSD.org> <3D57CF6D.2982CE8@mindspring.com> <3D58BFE8.9281433@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D58C359.A5F7B1AA>