On Thu, Jan 21, 1999 at 11:42:14AM -0800, Kurt D. Zeilenga wrote: > >This is nagging at me. Having two headers of the same name, but importantly > >different content is asking for touble. There needs to be a way to ensure > >that only one or the other is picked up. The best way I can think of is to > >only include the contents of the user thread pthread.h if _THREAD_SAFE is > >defined (to force people to use the right defines...) and the contents of > >kernel thread pthread.h if _REENTRANT (and not _THREAD_SAFE) is defined. > >This has the added bonus of meaning that most linux apps wont have to be > >patched. > > Of course, this would only work if the contents of the two pthread.h files > were merged. I'm not sure this is a good idea.
I'm not advocating any changes. But, IMO the best way to do it, if you did, wouldn't be to merge the files, but rather to re-implemnt pthread.h like: #ifdef LINUXTHREADS #include <..pointer to lt pthread.h file..> #else #include <..pointer to user thread pthread.h file..> #endif > If you did this, do NOT use -D_REENTRANT or -D_THREAD_SAFE as the conditional > to determine the content. Use -DLINUXTHREADS or something. Right. > 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. > > Also, the cc(1) says to use -D_THREADSAFE not -D_THREAD_SAFE. Hmm. Not on my machine. :) > 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. _REENTRANT should be used in all libc/libc_r and system headers to turn on generic thread safe options. > 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. 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: d...@tar.com 5182 N. Maple Lane phone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
