Date: Thu, 19 Nov 2009 12:11:13 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: threads@freebsd.org Subject: Re: Using pthread_once() in libc Message-ID: <Pine.GSO.4.64.0911191210000.8401@sea.ntplx.net> In-Reply-To: <200911191206.40934.jhb@freebsd.org> References: <200911191030.14151.jhb@freebsd.org> <Pine.GSO.4.64.0911191143300.8401@sea.ntplx.net> <200911191202.30738.jhb@freebsd.org> <200911191206.40934.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 19 Nov 2009, John Baldwin wrote: > On Thursday 19 November 2009 12:02:30 pm John Baldwin wrote: >> On Thursday 19 November 2009 11:48:54 am Daniel Eischen wrote: >>> On Thu, 19 Nov 2009, John Baldwin wrote: >>> >>>> I would like to provide a pthread_once()-like facility in libc that library >>>> bits can use to initialize data safely rather than trying to home-roll their >>>> own variants (see the recent commit to stdtime in libc). Ideally what I >>>> would like to do is have libc use the "real" pthread_once() when libthr is >>>> linked in and fall back to a simple stub without libthr linked in. I know we >>>> already do something like this for _spinlock() and friends. My question is >>>> what is the most correct way to do this? Should libc grow a new _once() >>>> symbol ala _spinlock() that is a weak symbol to a stub version and >>>> pthread_once() in thr_once.c would override that, or should there be a >>>> _pthread_once() in libc that is a stub in place of the current stub_zero? I >>>> noticed a comment in thr_spinlock.c saying the spinlock stuff is kept for >>>> backwards compat. Does this mean that for the future we would like to expose >>>> pthread symbols directly in libc? Meaning would we rather have libc export a >>>> pthread_once() and that ideally libc would be using pthread_mutex_lock/unlock >>>> instead of _spinlock/unlock? >>> >>> pthread_once() is already a stub in libc that gets overloaded with the >>> real thing when libthr is linked. See libc/gen/_pthread_stubs.c. >>> Isn't that what you want or does it not serve your purpose? >> >> Hmm, the libc stub will never run the init routine. I would like to do >> something like this: > > Perhaps this would work to fix pthread_once: No objection here. Still trying to figure out if that could potentially cause a problem with a dlopen()'d libthr. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0911191210000.8401>