Using pthread_once() in libc

[Daniel Eischen]

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