Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 21 Jan 1999 14:39:40 -0600
From:      "Richard Seaman, Jr." <dick@tar.com>
To:        "Kurt D. Zeilenga" <Kurt@OpenLDAP.Org>
Cc:        Jeremy Lea <reg@shale.csir.co.za>, freebsd-current@FreeBSD.ORG
Subject:   Re: Using LinuxThreads
Message-ID:  <19990121143940.D5495@tar.com>
In-Reply-To: <3.0.5.32.19990121114214.00958c30@localhost>; from Kurt D. Zeilenga on Thu, Jan 21, 1999 at 11:42:14AM -0800
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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: 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?19990121143940.D5495>