From owner-freebsd-threads@FreeBSD.ORG Wed Sep 24 16:47:51 2014 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B7FB57B4; Wed, 24 Sep 2014 16:47:51 +0000 (UTC) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EDDB19F2; Wed, 24 Sep 2014 16:47:50 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id a1so6094322wgh.1 for ; Wed, 24 Sep 2014 09:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=QsnUaocv7e6fBPeJUJXCh9cjIKK9DdE33NU12udj+ic=; b=uDOqpsj/rpN73Z5BRYDkevBEYw7rE5dJYE2ujsrZ6uFxL5B3hxdZdzasAbwj5Ibanz tIPUpeKVruqDG5n2nhsupb/xGwd3pg/hyezDnqNBzao9Wy0/qeCdK6A1kiL3Xw3FF8tI 73WCl/+BCWnqFqAohiSfaI1tm4YeO5vJLeVfV1epuRzOaC59f4ck5R9I4GasPa8jO3uG rM8NYcF5FTgjMmH94gZ9lYJoRjQuSQr1bzwiyHteggCRK5+UOYl6Bgy55cKEsuvM7wkm pxU/FCqqdZi3/J+iaYCcC2Mm2f7KtwAAb4X+pSM2uB4AwYF9SCdKYpBT5eZJOXKDBQvE mKuw== MIME-Version: 1.0 X-Received: by 10.180.9.144 with SMTP id z16mr30282349wia.26.1411577269271; Wed, 24 Sep 2014 09:47:49 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Wed, 24 Sep 2014 09:47:49 -0700 (PDT) In-Reply-To: <20140924151943.GM8870@kib.kiev.ua> References: <20140921213742.GA46868@stack.nl> <20140924143104.GK8870@kib.kiev.ua> <20140924144519.GL8870@kib.kiev.ua> <8951456.0ca4t8PBR9@ralph.baldwin.cx> <20140924151943.GM8870@kib.kiev.ua> Date: Wed, 24 Sep 2014 09:47:49 -0700 X-Google-Sender-Auth: ZO378nbzbYwHwR5lRkkA4Ii9SGY Message-ID: Subject: Re: sem_post() performance From: Adrian Chadd To: Konstantin Belousov Content-Type: text/plain; charset=UTF-8 Cc: Konstantin Belousov , freebsd-threads@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 16:47:51 -0000 If we have to break things in a big way, can we at least break them in a way that makes future work somewhat backwards compatible? This is all pretty painful looking :( -a On 24 September 2014 08:19, Konstantin Belousov wrote: > On Wed, Sep 24, 2014 at 11:04:28AM -0400, John Baldwin wrote: >> On Wednesday, September 24, 2014 05:45:19 PM Konstantin Belousov wrote: >> > I think it is even worse now. If the application linked against FBSD_1.0 >> > (ksem) semaphores implementation runs on the modern host, it cannot >> > share semaphore with modern binary. >> >> Correct. We changed sem_t's ABI hence the compat shims IIRC. > I mean, that new and old semaphores cannot IPC. > >> >> > Since this is not considered significant problem, we can avoid compat >> > code there as well. > By compat code I mean the switch on SEM_VERSION, not symversioning the > libc symbols. > >> >> I think if we leave sem_t alone there is no reason to create new compat >> shims for this change, but the existing FBSD_1.0 versions have to remain for >> people using old binaries, yes? > > Assume we applied new symver to semaphores which use new binary protocol > on the existing sem_t, and, to make it reasonable, use old protocol > when sem_t is accessed by older functions. Then, old binaries cannot > IPC with new binaries, although both are dynamically linked to libc. > IMO this is worse than the problem of different libc versions not > communicating.