From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) by sourceware.org (Postfix) with ESMTPS id EB54D3858C39; Wed, 8 Dec 2021 00:36:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EB54D3858C39 Received: by mail-wm1-x32d.google.com with SMTP id p27-20020a05600c1d9b00b0033bf8532855so687079wms.3; Tue, 07 Dec 2021 16:36:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZqtnOSg693Arg1HPm61hL3NjjZKy2igxlSWh9S98tLE=; b=Xq/QTxI39DBKdr+ohPkfXjIE2tx34q0TSEcS7iiZblWxGgFM65cCsLwaNED23T99GA DemB00zbvKHczstk5K4v4cKU1ahK3oZFOjRYLLq49970Xbc3dxKhqUfWrAq7viNY8uGe k1rUjdf+s797LMeXwKVXcjn5FveB/07ZF74r1v811jKfmZJd3N52HEd7YSfR8E4TN7Ih jBNOSZGcyIQ353oYgK5+M6fQ11FiTeBFg34i+m2586FSHbcAEMzKw/SS1MlnghKtLwXh 6YErhDdF340AbTbKuo5NZ0V1hz1kbYa1ptRVeYfeLtZchuw1lDpkl6QViodAqWTwQQC4 ByBg== X-Gm-Message-State: AOAM533QN2igPwQwmIMQrRKa7DPOqjj1J4Jan0llASTfkhT/hzTk2Fe1 1xvdlqhMwBFYsrRP7p+jVcUnbTjpLkB0/1y4iqY= X-Google-Smtp-Source: ABdhPJypaAaca+hWmyCbEGF8q2PZnay66THTROKyMGQXC0zP/qNonawn9KirmTVosHMU6I542PFAI/6TqUcXJOPznjM= X-Received: by 2002:a1c:488:: with SMTP id 130mr11507352wme.157.1638923772875; Tue, 07 Dec 2021 16:36:12 -0800 (PST) MIME-Version: 1.0 References: <20211207205803.1142706-1-jwakely@redhat.com> <871r2onmfg.fsf@oldenburg.str.redhat.com> <87tufkm6bb.fsf@oldenburg.str.redhat.com> In-Reply-To: <87tufkm6bb.fsf@oldenburg.str.redhat.com> From: Jonathan Wakely Date: Wed, 8 Dec 2021 00:36:01 +0000 Message-ID: Subject: Re: [PATCH] libstdc++: Allow std::condition_variable waits to be cancelled [PR103382] To: Florian Weimer Cc: "Jonathan Wakely via Libstdc++" , Jonathan Wakely , gcc-patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2021 00:36:15 -0000 On Tue, 7 Dec 2021 at 21:52, Florian Weimer wrote: > > * Jonathan Wakely: > > > On Tue, 7 Dec 2021, 21:20 Florian Weimer via Libstdc++, > > wrote: > > > > * Jonathan Wakely via Libstdc: > > > > > If necessary we could keep the terminate-on-cancellation behaviour a= s > > > _ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE@GLIBCXX_3.= 4.11 > > > and export the new behaviour as @@GLIBCXX_3.4.30, although this patc= h > > > doesn't do that. > > > > Note that if this fix escapes into the wild and then you have to make > > the symbol version change, you will break newer applications. In a fe= w > > cases in glibc, we proactively added aliases at a different symbol > > version, but with the same implementation (at first). > > > > To be safe, we probably should preserve the old behaviour for the old > > version of the symbol. If we decide that the new behaviour is always > > preferable, we could change that later by making the old symbol an > > alias for the new. If we don't decide that, we'll be glad we made it a > > separate symbol. > > On the other hand, with separate versions, it's possible to reintroduce > the old behavior at a later date, as a bugfix. It's not strictly > necessary to do that work upfront. It's just nice to have this option. Ah yes, a new symbol version gives us more flexibility in every direction. > > I'll see if I can get it working with two versioned symbols. We don't > > actually do that in libstdc++ currently, we only have a single version > > of every symbol. > > Ping me if you want to discuss options. 8-> Thanks. I'll try it and let you know how I get on. > Out of curiosity=E2=80=94do you support building libstdc++ (the shared ob= ject) > with a different compiler than the included GCC? No. Even using a different GCC is unsupported. I know of two people who've tried using clang, for reasons. But it's unsupported. You can use the installed libstdc++ headers and libs with other non-GCC compilers, but not other versions of GCC. But you can't build it with anything except the GCC built from the same revision of the source tree.