From: Terry Lambert <terry@lambert.org>
Message-Id: <199512061907.MAA01662@phaeton.artisoft.com>
Subject: Re: _thread_init stub in libc (fwd) RFC
To: julian@ref.tfs.com (Julian Elischer)
Date: Wed, 6 Dec 1995 12:07:27 -0700 (MST)
Cc: hackers@FreeBSD.org
In-Reply-To: <199512060718.XAA10573@ref.tfs.com> from "Julian Elischer" at Dec 5, 95 11:18:26 pm
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@FreeBSD.org
Precedence: bulk

> Ok, this has come up for the thread support..
> 
> what is the  consensus?
> is this right?
> 
> julian
> 
> > >From the *crt0 code, we need to call _thread_init(). Since gcc likes to
> > >go get crt0, it doesn't make sense to have a separate set. We cannot force
> > >a programmer to the the *right* crt0 when linking against libc_r.a.
> > 
> > To solve this, I'd like to add a sub for _thread_init() to the normal libc,
> > so that all applications use the same crt0 set regardless of whether or not
> > they are threaded. The overhead of calling _thread_init() when a program
> > starts shouldn't be a big deal.

Why does _thread_init() need to be called from crt0?

What is the call graph of allowable functions?

I believe that create_thread() could use a static to do the initialization
on the first call.

The problem with calling _thread_init() in each case is that for a
cooperative task model (which may be desirable), the scheduler thread
is the main thread and an init is what forks off the main thread from
the scheduler thread... basically, a shell game.


I would *strongly* recommend looking at the initialization sequence
for the more recent bind code, which was changed to be "shared library
friendly" (breaking older revs of sendmail 8-) at the same time).


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.