From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) by sourceware.org (Postfix) with ESMTPS id 0698B385703A for ; Fri, 21 May 2021 11:31:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0698B385703A Received: by mail-qt1-x82b.google.com with SMTP id t20so15003053qtx.8 for ; Fri, 21 May 2021 04:31:50 -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:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=YxRlWxTukkCiHPZGtl+49yIpww6W3FG8GwlNYmQ6qTs=; b=VsvyPyu4ds1dwQCvMIvSKoWgSrYjps5n2E6tV5HcyiidAXw0wS3fgNdp6ccxfaqvBR E0sWn+iYYMLC24sg7NCEZBOLOdhUnDW6zbJSeDidZKzX4zcs7u6fU5rGe9+Lu/fuzrY0 S5h/dmLf6aaZS68P0WUvtL82w+3NIha/KOcwJ8FGaGKF0hnsW9GL27HSWUTkzSKL/t3b emEQYv9CA4IkCnxRx04Jd+lPI46tK8D1EY0FmLn/ScLOIb/ITo78BEcPDGNCV7SVFP6P jfXBFXY06RcR9X+TGxEaohV47zSvn6w09OeE33DYM7u0Y6EMIEKM/pGLFMc/kn7FSF5M 08OQ== X-Gm-Message-State: AOAM530DY+nIYipvArBbDtgtA1EwQOTP5nNnoRNHMWfwR1uVmsSuZ+iJ sXWw6LP2LaD8h4Ju1BrL3arAO/vWAzLTRQ== X-Google-Smtp-Source: ABdhPJzlsyBLJjxcW+p45g8C7Xt1XuCjwlj5a3CVFa+QYbLoPpR5zwIYiYs8V6VEAGdDJ+lLG+KSsQ== X-Received: by 2002:ac8:647:: with SMTP id e7mr10866789qth.156.1621596709383; Fri, 21 May 2021 04:31:49 -0700 (PDT) Received: from [192.168.1.4] ([177.194.37.86]) by smtp.gmail.com with ESMTPSA id z18sm4323768qki.55.2021.05.21.04.31.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 May 2021 04:31:49 -0700 (PDT) Subject: Re: [PATCH 01/10] nptl: Perform signal initialization upon pthread_create 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> From: Adhemerval Zanella Message-ID: Date: Fri, 21 May 2021 08:31:46 -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: <87tumwcsrx.fsf@oldenburg.str.redhat.com> 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 11:31:51 -0000 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. > > So I think we should go with my original version for the time being. We > can switch to lazy initialization if we implement a different way for > handling late thread creation failure. Alright, I think we can change it later. > > SIG_IGN handler disposition should not affect timer_create (which uses > SIGCANCEL internally) because sigwaitinfo still wakes up on such > signals. > > Thanks, > Florian >