Date: Wed, 6 Dec 1995 12:07:27 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: julian@ref.tfs.com (Julian Elischer) Cc: hackers@freebsd.org Subject: Re: _thread_init stub in libc (fwd) RFC Message-ID: <199512061907.MAA01662@phaeton.artisoft.com> In-Reply-To: <199512060718.XAA10573@ref.tfs.com> from "Julian Elischer" at Dec 5, 95 11:18:26 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512061907.MAA01662>