From owner-freebsd-hackers Wed Dec 6 11:09:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA11249 for hackers-outgoing; Wed, 6 Dec 1995 11:09:14 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA11244 for ; Wed, 6 Dec 1995 11:09:13 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA01662; Wed, 6 Dec 1995 12:07:28 -0700 From: Terry Lambert 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 X-Mailer: ELM [version 2.4 PL24] 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.