Date: Fri, 8 Dec 1995 07:46:25 +1100 (EST) From: John Birrell <cimaxp1!jb@werple.net.au> To: lambert.org!terry@werple.net.au (Terry Lambert) Cc: hackers@FreeBSD.org, jb@cimlogic.com.au Subject: Re: _thread_init stub in libc (fwd) RFC Message-ID: <199512072042.HAA15327@werple.net.au> In-Reply-To: <199512071818.LAA05138@phaeton.artisoft.com> from "Terry Lambert" at Dec 7, 95 11:18:29 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512072042.HAA15327>