From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) by sourceware.org (Postfix) with ESMTPS id 889173858025 for ; Fri, 21 May 2021 12:40:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 889173858025 Received: by mail-qk1-x731.google.com with SMTP id v8so19551028qkv.1 for ; Fri, 21 May 2021 05:40:57 -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:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4Q/wqUTD0qD5hKK4FLxYKOUdLeg80/+dmoKlgODjFA4=; b=A+L00DNhV78jovpgz/Zl574ldTcZiteoXtPmD8rVdjguS3Fd94rH9SfvNut/kQMFY6 FD7RxDxUhMb84DoI7EyLx1AQ4FUvGDI4IB4v/Yb6rw5tUPmENGfW768VYXvuXW1fXgSw hKF+K0pbJqh8UroZIyDl7ZutuVtJykWOwNallN6/+UPeI0daLZO+zoFbVrFWYq855dYy zzqXqGQE8sSLmuPuL35A933M/F8yZfO7mepGBHslG5k+mSPNJrAbY47QaV9FTwqc31Af nV6Jf4oA+C/7Jo+FYFeUOxGZUJk8krkGBcaGTb6b4snnbN1m7SXsaljSFORAGjMDKnPd srZg== X-Gm-Message-State: AOAM531Mwui8tTR9PYaMyWwtEnrcDAIIodFna3BYkPqzL4inkyWv3yT6 s73YqgkHuzvq1wBgjdnOgVa2RMdHrpNmJA== X-Google-Smtp-Source: ABdhPJyOl4GFVPOhkJ8mtLldXB5iJ8UzFG2B/nNPhBXV7Al5T5k9YvYESknPv53/LWg+JtsWM7iBtg== X-Received: by 2002:a05:620a:9c4:: with SMTP id y4mr12012004qky.60.1621600856887; Fri, 21 May 2021 05:40:56 -0700 (PDT) Received: from [192.168.1.4] ([177.194.37.86]) by smtp.gmail.com with ESMTPSA id x27sm4648382qkj.133.2021.05.21.05.40.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 May 2021 05:40:56 -0700 (PDT) Subject: Re: [PATCH 01/10] nptl: Perform signal initialization upon pthread_create From: Adhemerval Zanella To: Florian Weimer Cc: libc-alpha@sourceware.org References: <87bl95jiqs.fsf@oldenburg.str.redhat.com> <46b68c50-e1d9-1450-d3ea-a302b86e2949@linaro.org> <87wnrti31f.fsf@oldenburg.str.redhat.com> <91fc0623-3f90-e5e9-2149-454c781dfc33@linaro.org> <87tumwcsrx.fsf@oldenburg.str.redhat.com> Message-ID: <3c876bdd-aba4-4450-623a-0d071b82670a@linaro.org> Date: Fri, 21 May 2021 09:40:54 -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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.7 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: Fri, 21 May 2021 12:40:59 -0000 On 21/05/2021 08:31, Adhemerval Zanella wrote: > > > On 21/05/2021 06:58, Florian Weimer wrote: >> * Adhemerval Zanella: >> >>>>> Bu the main advantage is to move the cancellation code logically when >>>>> it is actually used, and it is small improvement on both static >>>>> linking (since the static code will be used solely is cancellation is >>>>> used) and on runtime (since sigaction will be set only if pthread_cancel >>>>> is called). >>>> >>>> Okay, I can prepare a version along these lines. But in general, I >>>> consider less data and fewer conditionals an improvement. >>> >>> Thanks. >> >> Unfortunately, it does not work with the present implementation. >> >> sysdeps/unix/sysv/linux/createthread.c contains this: >> >> /* The operation failed. We have to kill the thread. >> We let the normal cancellation mechanism do the work. */ >> >> pid_t pid = __getpid (); >> INTERNAL_SYSCALL_CALL (tgkill, pid, pd->tid, SIGCANCEL); >> >> This obviously needs a working SIGCANCEL handler, so pthread_create and >> pthread_cancel are not as separate as we thought. > > We can use __libc_signal_block_app on pthread_create instead of > __libc_signal_block_all and call __pthread_cancel on createthread. The > SIGCANCEL is internal, so the race condition should not happen (assuming > well behave programs). The pthread_cancel call on createthread can then > enable the signal. Ok, I didn't realize the current approach does require the SIGCANCEL handler to be active so and invalid affinity mask or scheduler can cancel the thread execution.