first patch for process-shared semaphore

[John Baldwin]

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.

-- 
John Baldwin