Date: Wed, 6 Dec 2000 22:48:27 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: brian@Awfulhak.org (Brian Somers) Cc: xyf@stocke.com (xuyifeng), freebsd-arch@FreeBSD.ORG, brian@Awfulhak.org Subject: Re: Threads in the base system Message-ID: <200012062248.PAA25916@usr08.primenet.com> In-Reply-To: <200012062137.eB6Lb0t07362@hak.lan.Awfulhak.org> from "Brian Somers" at Dec 06, 2000 09:37:00 PM
next in thread | previous in thread | raw e-mail | index | archive | help
> I don't think it's possible to mix libc and libc_r in the same > program (except as intended - with the libc_r stubs superseding the > libc ones). > > There are no ``alternative'' header files with different defines that > might be used in one object and not the other, and the program is > either linked against libc_r, or isn't (and will fail if it's got > thread references). From my reading, there is still code in header files that is compiled variant based on _THREAD. This means that calling libraries compiled with threading disabled from code that was compiled with threading enabled _may_ result in undefined behaviour (I haven't tracked down every instance, and I think an audit would be needed to know for sure). In general, it's possible to set up an "apartment" or "rental" model threading interface to wrap such libraries to make sure things work. Work has to be queued for a worker thread, and the worker thread does the work and queues the response. Only the worker thread can be allowed into the library. This is basically how you have to use the thread-unsafe LDAP libraries on Windows (or any system that has thread local storage that is not mapped into the global process address space -- what a design mistake). This assumes that with or without _THREAD, the code doesn't change, though... I guess the real question is, if you were to rename libc, so that things couldn't link against it, modify the libc_r to include a linkage against the renamed library so it pulls in things it doesn't define from libc instead, and then make symlinks from libc to point to libc_r instead, would things still work, or are there some things that would break? As far as eating the threading overhead in unthreaded programs, the decision to eat the overhead has already been taken; it happened whenEGCS became the default compiler, since EGCS doesn't support dynamic registration of threads support code (e.g. per thread exception stacks in C++ via libgcc). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200012062248.PAA25916>