Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 2 Jul 1998 08:41:52 +1000 (EST)
From:      John Birrell  <jb@cimlogic.com.au>
To:        jabley@clear.co.nz (Joe Abley)
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: pthreads
Message-ID:  <199807012241.IAA01186@cimlogic.com.au>
In-Reply-To: <Pine.BSF.3.96.980702080311.2083A-100000@buddha.clear.net.nz> from Joe Abley at "Jul 2, 98 08:09:39 am"

next in thread | previous in thread | raw e-mail | index | archive | help
Joe Abley wrote:
>   #define _REENTRANT
>   #include <pthread.h>

If 2.2.X:

#define _THREAD_SAFE
#include <pthread.h>

If 3.0:

#include <pthread.h>

> at the top of the source files, and link with -lpthread. With FreeBSD the
> linking phase is more involved, since I need to exclude the standard C
> libraries and link with libc_r instead.

The thread code was first added to 3.0-current and was merged back to
the 2.2 tree without the gcc change that added the -pthread argument
which selects the libraries properly.

> 
> Why was the decision made to support pthreads in this manner?

I wasn't allowed to destablize libc.

> What
> benefits does this have over the Solaris way of doing things?

I doubt there are any.

> 
> 2. Should I really be using the 2.2.6-RELEASE libc_r pthread support, or
> should I be looking at Chris Provenzano's pmpthreads?

You haven't said what FreeBSD version you're running. Since the 2.2.6
release there have been a few fixes for boundary conditions like reading
and writing zero bytes, etc.

> I'm by no means any kind of expert on posix threads; I've just been
> working on some code which compiled but refused to run properly on
> FreeBSD. Moving the code to Solaris (and removing all the nice BSD
> networking code which Sun have seen fit not to support on Solaris), it
> compiled and worked fine, no problems.

If you can isolate the problem with a test program, please send me the
test code. Remember that the code in libc_r is a user-space implementation
so it is easy for application code to interfere with the operation of
the thread library. The worst cases of this that I've seen are those
that use GNU configure scripts that incorrectly choose options.

-- 
John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/
CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137

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?199807012241.IAA01186>