Message-Id: <199512072042.HAA15327@werple.net.au>
From: John Birrell <cimaxp1!jb@werple.net.au>
Subject: Re: _thread_init stub in libc (fwd) RFC
To: lambert.org!terry@werple.net.au (Terry Lambert)
Date: Fri, 8 Dec 1995 07:46:25 +1100 (EST)
Cc: hackers@FreeBSD.ORG, jb@cimlogic.com.au
In-Reply-To: <199512071818.LAA05138@phaeton.artisoft.com> from "Terry Lambert" at Dec 7, 95 11:18:29 am
Content-Type: text
Sender: owner-hackers@FreeBSD.ORG
Precedence: bulk

> > > What is the call graph of allowable functions?
> > 
> > Huh???
> 
> What do you have to call in what order, from first to last, to get the
> thing to work, so we can pick something at the front of the list and
> toenail it in there with:
> 
> 	static int once = 0;
> 
> 	if( !once) {
> 		once = 1;
> 		_thread_init();
> 	}

Oh, I see what you mean. 8-). Other than _thread_init(), there are no other
functions you _have_ to call. You just call the libc functions as you need
them. Or the pthread_* functions for thread functionality.

> 
> > We don't have a create_thread function. If you mean pthread_create, this is
> > not called for the initial thread. The initialisation still has to be
> > performed regardless of whether or not you create another thread.
> 
> What about a non-threaded program?

I can't avoid overhead in using a threaded library with a non-threaded
program. We'll always have file and malloc locking. I don't think that it
is practical to try to turn this on only when there is more than one thread.
We're doing a libc_r.a so that non-threaded programs never have any of this.
The only things (that I can think of now) that I want to see in libc are
a stub for _thread_init() and a __error() function that returns a pointer
to the global errno (and cerror.S changed to call __error). We're leaving
the errno/__error bit until later. It's the _thread_init() stub we need now.

> 
> I'm thinking to delay the "initial thread" until the first "pthread_create"
> to create a second thread.

This causes a problem because signal handling is done on a thread-by-thread
basis. This is an area where our thread implementation differs from the MIT
pthreads. We build the sigaction syscall as _thread_sys_sigaction(), for
instance. In the threaded library we provide a sigaction() function which
writes to fields in the thread structure. So if one of the first things
that a programmer does is to set up signal handling in main(), then for the
initial thread we have to at least call _thread_init() by then.

I guess we could make the initial thread use a global structure, instead of
the global pointer to a malloced thread structure. But then we have to
check for initialisation in all the possible libc functions that the
programmer *might* call. I'd like to avoid this.

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


-- 
John Birrell                                CIMlogic Pty Ltd
jb@cimlogic.com.au                          119 Cecil Street
Ph  +61  3 9690 9600                        South Melbourne Vic 3205
Fax +61  3 9690 6650                        Australia
Mob +61 18  353  137