first patch for process-shared semaphore

[Daniel Eischen]

On Dec 28, 2009, at 3:04 PM, Alexander Kabaev <kabaev at gmail.com> wrote:

> On Mon, 28 Dec 2009 11:21:30 -0500
> John Baldwin <jhb at freebsd.org> wrote:
>
>> On Monday 28 December 2009 2:18:17 am David Xu wrote:
>>> John Baldwin wrote:
>>>> On Wednesday 23 December 2009 10:12:19 pm Alexander Kabaev wrote:
>>>>> On Thu, 24 Dec 2009 09:58:50 +0800
>>>>> David Xu <davidxu at freebsd.org> wrote:
>>>>>
>>>>>> Alexander Kabaev wrote:
>>>>>>> On Thu, 24 Dec 2009 09:22:34 +0800
>>>>>>> David Xu <davidxu at freebsd.org> wrote:
>>>>>>>> libthr does not require semaphore, it implements semaphore,
>>>>>>>> it is easier than other ways to implement the process-shared.
>>>>>>>>
>>>>>>> Let me rephrase: I do not think semaphores belong in libthr.
>>>>>>> They should be either in libc or in librt.
>>>>>>>
>>>>>>>
>>>>>> OK, does others really implement semaphore in librt ?
>>>>>> unfortunately, the librt already requires libpthread to
>>>>>> implement SIGEV_THREAD.
>>>>> I retract that. It appears that there is no consistency -
>>>>> Solaris put these into libc, Linux into libpthread ans SUSv2
>>>>> hints that these belong with realtime functions. libthr is fine.
>>>>
>>>> I vote for libc.  Single-threaded processes can use sem_open()
>>>> and PSHARED sem_init() as well.  Single-threaded processes can
>>>> even use non-PSHARED sem_init() by using fork() to create new
>>>> "threads" that share the
>> semaphore.
>>>>
>>> May I can move all semaphore functions into libc and remove all
>>> semaphore related symbols from libthr ? In pratical, this is not a
>>> problem, because libthr itself is not dlopen-safe, all missing
>>> semaphore functions in libthr will be found in libc by rtld.
>>
>> I would go with this approach.  There is also some discussion about
>> moving all of libthr into libc as well and having a dummy libpthread
>> now that we are back to a single threading library and to avoid
>> issues with dlopen() of libpthread, etc.
>>
>
> Removing symbols from library, versioned library especially, is a big
> wrong. You should provide compat symbols for all functions that that
> were there before.

I tend to agree.  I also don't understand the desire to include libthr  
in libc.  Other than dlopen()ing libpthread (which can be worked  
around other ways), I don't understand why we would need or want this.

-- 
DE