Date: Mon, 28 Dec 2009 15:51:19 -0500 From: John Baldwin <jhb@freebsd.org> To: Alexander Kabaev <kabaev@gmail.com> Cc: Daniel Eischen <deischen@freebsd.org>, David Xu <davidxu@freebsd.org>, freebsd-threads@freebsd.org Subject: Re: first patch for process-shared semaphore Message-ID: <200912281551.19942.jhb@freebsd.org> In-Reply-To: <20091228150423.201936b4@kan.dnsalias.net> References: <4B317741.8080004@freebsd.org> <200912281121.30939.jhb@freebsd.org> <20091228150423.201936b4@kan.dnsalias.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 28 December 2009 3:04:23 pm Alexander Kabaev wrote: > On Mon, 28 Dec 2009 11:21:30 -0500 > John Baldwin <jhb@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@freebsd.org> wrote: > > > >> > > > >>> Alexander Kabaev wrote: > > > >>>> On Thu, 24 Dec 2009 09:22:34 +0800 > > > >>>> David Xu <davidxu@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. So can you have a 1.1 sem_init() in libthr that calls the 1.2 sem_init() in libc? I'm ok with simple compat stubs. In this case the compat stubs might actually need to do work though since they would need to malloc() a separate cookie structure to map from the "old" semid_t that was just a pointer to the new structure. Presumably even libc would need 1.1 compat shims in this case, too. Not sure if you can have libthr's compat shims call the compat shims in libc somehow to avoid code duplication. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200912281551.19942.jhb>