From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 7DD2F3858D3C for ; Wed, 8 Dec 2021 18:14:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7DD2F3858D3C Received: from mail-yb1-f197.google.com (mail-yb1-f197.google.com [209.85.219.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-562-Osp_4SYkNn26YgSxDKjmSQ-1; Wed, 08 Dec 2021 13:14:53 -0500 X-MC-Unique: Osp_4SYkNn26YgSxDKjmSQ-1 Received: by mail-yb1-f197.google.com with SMTP id l145-20020a25cc97000000b005c5d04a1d52so5759876ybf.23 for ; Wed, 08 Dec 2021 10:14:53 -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; bh=oRF7L+Xedw2YdhOKtAyWGF3aDXjSSl5hQOgQ+12EBAA=; b=dkAt4j3z6foespix3oZS2s8c4I2BrFpDfxpsYOiDUSeQ+qgvlPVeAoJXLmTmXIoIiH z8weAmfqqaiONGs7XbfajTtCO/XxnW2ujllK0M9ATG6hh2SglrZY7ALWpb9HEefiNrC+ S0+hNkmQY8SQj7qi3qHjoI56oBQwiws3Q34e7rBuir/eZjjBSdSlpumDnMOPhFe3Ol5T HBIrvIHeCrGRV0MdqxPtbv8TKYPME3WI7lppMY7ClZfbn0YxOjfanq69SUKgoJnmo4by EVaismAGTAh8xPqZ/x/SjWGvfqDJfeJ89SwnkRIO891bXkkkVu3Dxg1HEQFg/MdqCOZE rfmg== X-Gm-Message-State: AOAM532tSs9m2C1qAZ/4XEYvwWUX1O/joSL8Hwj768TUcu+XrLz64ztn bl6WReq/yjwtQPPq+9ZHiNN1hvlmTVCc0cgUe41niWteqgKXAL8v3fOGScBc1U2uRTllty+aM0l Gmojy4yYBJCDfMr+aSdMSrN8rcwQVxyk= X-Received: by 2002:a25:f608:: with SMTP id t8mr282034ybd.667.1638987292210; Wed, 08 Dec 2021 10:14:52 -0800 (PST) X-Google-Smtp-Source: ABdhPJz6lg0gxZlfxY5NgMdHky1TDLgc1OiUVsVk29y2xXfL5fdXq+ImHhxbJYGDVVbcAEPgvnnmCr7r+g6MlG3u+ZU= X-Received: by 2002:a25:f608:: with SMTP id t8mr282018ybd.667.1638987292007; Wed, 08 Dec 2021 10:14:52 -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: From: Jonathan Wakely Date: Wed, 8 Dec 2021 18:14:41 +0000 Message-ID: Subject: Re: [PATCH] libstdc++: Allow std::condition_variable waits to be cancelled [PR103382] To: Ville Voutilainen Cc: Jonathan Wakely , Florian Weimer , "Jonathan Wakely via Libstdc++" , gcc-patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, 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 18:14:55 -0000 On Wed, 8 Dec 2021 at 17:36, Ville Voutilainen wrote: > > On Wed, 8 Dec 2021 at 19:27, Jonathan Wakely via Libstdc++ > wrote: > > After resolving a PEBKAC issue, here's an incremental diff that > > preserves the old behaviour for the existing @GLIBCXX_3.4.11 symbol, > > but adds a new @@GLIBCXX_3.4.30 symbol that supports cancellation via > > __forced_unwind. > > > > Maybe we should also do this in the implementation of the old noexcept function: > > > > __attribute__((used)) > > void > > __nothrow_wait_cv::wait(std::unique_lock& lock) noexcept > > { > > int old; > > int err = pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &old); > > this->condition_variable::wait(lock); > > if (!err && old != PTHREAD_CANCEL_DISABLE) > > pthread_setcancelstate(old, &old); > > } > > > > This would prevent cancellation from terminating a process if it uses > > the old symbol. So we'd have a new symbol that supports cancellation, > > and an old one that safely disables it. > > That sounds good to me. I think I'll disable cancellation as a separate change, because it's not what the existing symbol does, and we should look at doing it anywhere else that will currently terminate. > Also, I'm not sure it was pointed out, for the original: changing a > noexcept function to start throwing can leak exceptions > through other noexcept functions, hitting catch-blocks instead of > terminates, or terminates that occur much later > than intended. The compiler will assume that it doesn't need to set up > the LSDA in a noexcept function if everything > you call is noexcept, and then you don't have the LSDA that would > terminate right then and there. That's probably > a lesser problem for the thread cancellation exception than it would > be for some others, but it's a blood-curdling/chilling possibility > that we should just avoid. And you have done that, thanks for that. Yes, and those kind of problems are probably more likely in practice, because the compiler *always* treated that function as noexcept. Users probably didn't care whether it was or not (and it isn't guaranteed to be by the standard) so wouldn't have gone out of their way to write code that depended on it being noexcept.