Date: Thu, 21 Jan 1999 14:00:53 -0800 From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.Org> To: "Richard Seaman, Jr." <dick@tar.com> Cc: freebsd-current@FreeBSD.ORG Subject: -D_REENTRANT (Was: Using LinuxThreads) Message-ID: <36A7A395.29B3E8A7@OpenLDAP.Org> References: <19990119091151.F600@tar.com> <19990118182717.A15566@top.worldcontrol.com> <Pine.BSF.4.05.9901182203500.11971-100000@janus.syracuse.net> <19990119024539.A88383@top.worldcontrol.com> <19990119140613.B826@shale.csir.co.za> <19990119091151.F600@tar.com> <19990121181228.A98581@shale.csir.co.za> <3.0.5.32.19990121114214.00958c30@localhost> <19990121143940.D5495@tar.com>
next in thread | previous in thread | raw e-mail | index | archive | help
"Richard Seaman, Jr." wrote: > > BTW, why does FreeBSD use -D_THREAD_SAFE AND -D_REENTRANT (math.h) > > while most other PThread (final) implementations use -D_REENTRANT? > Don't know. Using _REENTRANT would be preferable, IMO. Now if only a committer would agree... (I'll send patches if needed). > > Also, the cc(1) says to use -D_THREADSAFE not -D_THREAD_SAFE. > Hmm. Not on my machine. :) http://www.freebsd.org/cgi/man.cgi?query=cc&apropos=0&sektion=0&manpath=FreeBSD+3.0-current&format=html > > Personallly, I think -DREENTRANT should be used for include all prototypes > > for reentrant functions not requiring thread support (like strtok_r) and > > -D_THREAD_SAFE routines only implemented in -lc_r. > > I think _THREAD_SAFE should be used as a switch when compiling libc/libc_r to > turn on libc_r specific options, which is how it is primarily used now. Then it shouldn't be used in the headers if at all possible! > _REENTRANT should be used in all libc/libc_r and system headers to turn on > generic thread safe options. -D_REENTRANT should turn on reentrant functions, some of which may or may not be thread safe, that do not require threading support to implement. Reentrant functions that require threading support to implement should only be behind a different define. I think the problem is that folks tend to think the reentrant functions are only for use in threaded applications. They are quite useful in non-threaded applications as well (especially strtok_r). > > If possible, functions > > should be implemented in both -lc and -lc_r such that 3rd party libraries > > wouldn't have to create both a -lfoolib vs. -lfoolib_r versions (unless > > their _r versions requires threading). > > For kernel threading you just use libc. Whether or not libc generates > thread safe (re-entrant) calls depends on whether its also linked with > a library that 1) sets __isthreaded to a non-zero value, 2) has a _spinlock() > implementationm, and 3) implements the functions flockfile, funlockfile, etc. > There are also a few macros in header files that require _THREAD_SAFE to > be defined to be thread safe. I was hoping to be able to produce one ldap library that could be safely linked with or without threads. However, if I must define _THREAD_SAFE to generate code to be linked with threads then I must produce two libraries (-lfoolib compiled with -U_THREAD_SAFE and -lfoolib_r with -D_THREAD_SAFE). This is quite painful. Many 3rd packages won't go through the pain. They will generate one library and assume all users will compile/link with compatible flags. Of course, most users don't know how their libraries were built nor pay much attention when configure dependent software. We run into this big time with OpenLDAP and third party packages such as DB2. It gets real complicated with try to link with multiple third party libs which may or may not be compiled with -D_THREAD_SAFE. errno was the biggest problem, but its conditional declaration of it has long since been removed. 3rd party library implementors need to be careful when using any function with a conditional declaration as you don't know which you'll get when an application is linked. We also only use reentrant functions where exist in -lc and avoid functions such as feof that may have conditional declarations. This allows us to build one -lldap that *can be* safely used by both threaded and non-threaded applications. > libc_r could be modified so that is doesn't replace libc, but rather is > an addon, comparable to the kernel threaded libc case. But, it would > involve a bit of work. > > -- > Richard Seamman, Jr. email: dick@tar.com > 5182 N. Maple Lane phone: 414-367-5450 > Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36A7A395.29B3E8A7>