From owner-freebsd-threads@FreeBSD.ORG Mon Dec 28 20:55:47 2009 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C98910656B7; Mon, 28 Dec 2009 20:55:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 04A728FC1C; Mon, 28 Dec 2009 20:55:47 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 9912E46B0D; Mon, 28 Dec 2009 15:55:46 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id BDFD68A01B; Mon, 28 Dec 2009 15:55:45 -0500 (EST) From: John Baldwin To: Alexander Kabaev Date: Mon, 28 Dec 2009 15:51:19 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091103; KDE/4.3.1; amd64; ; ) References: <4B317741.8080004@freebsd.org> <200912281121.30939.jhb@freebsd.org> <20091228150423.201936b4@kan.dnsalias.net> In-Reply-To: <20091228150423.201936b4@kan.dnsalias.net> MIME-Version: 1.0 Message-Id: <200912281551.19942.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 28 Dec 2009 15:55:45 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Daniel Eischen , David Xu , freebsd-threads@freebsd.org Subject: Re: first patch for process-shared semaphore X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Dec 2009 20:55:47 -0000 On Monday 28 December 2009 3:04:23 pm Alexander Kabaev wrote: > On Mon, 28 Dec 2009 11:21:30 -0500 > John Baldwin 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 wrote: > > > >> > > > >>> Alexander Kabaev wrote: > > > >>>> On Thu, 24 Dec 2009 09:22:34 +0800 > > > >>>> David Xu 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