From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) by sourceware.org (Postfix) with ESMTPS id 04E8D3850400 for ; Wed, 2 Jun 2021 13:09:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 04E8D3850400 Received: by mail-qv1-xf2d.google.com with SMTP id e18so1215720qvm.10 for ; Wed, 02 Jun 2021 06:09:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=z6Wi6DgS46lS1eO5U3JGzTxZXotwf2DIFFzkuA+IcFE=; b=TW6g9MWGsyZ7FKObIKD0tzJY4qAuYBMaOmKjnQfBfsJ6RcnTYL3eyt87a1Z0jfHqHP L1T26sH0c5+xAESyArIA5BPXsx7mxj8dBnUbP+aPmQh2/cH5yC2mNVcejXbmFyHlJ++b GMWKA3B4uEtM/CkqnEuDVWVBVnsNf3YOUuL4qmBWD9HnoRt6f/5H+HWAxAuwSIKA0okP 32rINEKvwjhPCFCNcgBnxYsAFrrgGGyQWsCwUdXdqiNwvvuZgEf2phqE5sjLf+Yr7uX8 B6tt1lc2jM21MbSUEQtuoe90zEqu7xxJgApTqZyK4J0YlxtgpCB93BCrGStjq9VkvTba /OUg== X-Gm-Message-State: AOAM533/2QlsltOcoHSGAWz0IVMYd6yAvNuFWEOeOoa03je2ZVAMMc75 4ZTl47jarSoL03rqr1lDNqURIhCQ+KYhHw== X-Google-Smtp-Source: ABdhPJy5B2HhHYwpRijE7NmEQqUcUHa19OZsRH4eHLhgogzFcQP3LN4px+4qD+T1tGVYvG9H24ImRg== X-Received: by 2002:a05:6214:930:: with SMTP id dk16mr1270419qvb.29.1622639391465; Wed, 02 Jun 2021 06:09:51 -0700 (PDT) Received: from [192.168.1.4] ([177.194.59.218]) by smtp.gmail.com with ESMTPSA id p16sm10777265qtq.79.2021.06.02.06.09.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Jun 2021 06:09:51 -0700 (PDT) Subject: Re: [PATCH v2 5/9] nptl: Move cancel state out of cancelhandling To: Florian Weimer , Adhemerval Zanella via Libc-alpha References: <20210527172823.3461314-1-adhemerval.zanella@linaro.org> <20210527172823.3461314-6-adhemerval.zanella@linaro.org> <877djd7vpo.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Message-ID: <9433905d-061f-0290-1483-96015f48239d@linaro.org> Date: Wed, 2 Jun 2021 10:09:49 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <877djd7vpo.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2021 13:10:02 -0000 On 01/06/2021 06:58, Florian Weimer wrote: > * Adhemerval Zanella via Libc-alpha: > >> Now that thread cancellation state is not accessed concurrently anymore, >> it is possible to move it out the 'cancelhandling'. >> >> The code is also simplified: the CANCELLATION_P is replaced with a > > Drop “the”? Ack. > >> internal pthread_testcancel call and the CANCELSTATE_BIT{MASK} is >> removed. >> >> The second part of this patchset also keeps the pthread_setcanceltype as >> cancellation entrypoint by calling pthread_testcancel if the new type >> is PTHREAD_CANCEL_ASYNCHRONOUS. > > What do you mean by “patchset” in this context? It's in the same > commit, right? I did not update this comment with recent rebase. I will just remove this paragraph. > >> With this behavior pthread_setcancelstate does not require to act on >> cancellation if cancel type is asynchronous (is already handled either >> by pthread_setcanceltype or by the signal handler). > > Is this really true? What is supposed to happen with a pending > asynchronous cancellation request if cancellation is disabled for the > target thread? Isn't it supposed to be queued if it's a self-cancel? POSIX does not really define pthread_setcancelstate as a cancellation entrypoint [1]. And the pthread_cancel already queue the cancellation by setting the CANCELED_BITMASK, the cancellation will be acted upon on next cancellation entrypoint when cancellation is enabled. [1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html