From owner-freebsd-hackers Thu Dec 7 13:28:35 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA23397 for hackers-outgoing; Thu, 7 Dec 1995 13:28:35 -0800 (PST) Received: from werple.net.au (werple.mira.net.au [203.9.190.18]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id NAA23390 for ; Thu, 7 Dec 1995 13:28:28 -0800 (PST) Received: from cimaxp1.UUCP (Ucimlogi@localhost) by werple.net.au (8.7/8.7.1) with UUCP id HAA15327 for hackers@FreeBSD.org; Fri, 8 Dec 1995 07:42:17 +1100 (EST) Message-Id: <199512072042.HAA15327@werple.net.au> X-Authentication-Warning: werple.net.au: Ucimlogi set sender to cimaxp1!jb using -f Received: by cimaxp1.cimlogic.com.au; (5.65/1.1.8.2/10Sep95-0953AM) id AA29899; Fri, 8 Dec 1995 07:46:26 +1100 From: John Birrell 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 X-Mailer: ELM [version 2.4 PL23] 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