From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) by sourceware.org (Postfix) with ESMTPS id 6F1693854830 for ; Tue, 25 May 2021 12:29:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6F1693854830 Received: by mail-qt1-x830.google.com with SMTP id s12so13743215qta.3 for ; Tue, 25 May 2021 05:29:23 -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=3PmfnYEER8h3c396PONpKYuv0BVXCYrx78Q5WjgiPfs=; b=tpWs0vOTUq2aGLd6d5CZDBeZVDNrPLf+2gXNxClwCq+C8+nxnsBxNoVryoJ2f5pEcO SbAoyaj+S0oIaLrKfqr12UgF6XEBKMmVwUVWGf63Pest6ySTT2h7d+Do7jy46ZzaAI9G IOz0g89x77zGendhLeIiTB3NHOLRt/az9roIFpuKqLQPwqoer4G++OS9DfVt1n5vW14h SO5CQnOWUSNyGr2keG8H9GiED0dEyvOHOLTPv7xOv5gC0KR3J01IjnCyRO8rMxwmpeTx k+U9TIL6Je1M6fnTt3er2F5boVhX1u9o51XzWOmX+QX1tRM+M8ub1Ec7BvkFlGL1A5YK Bqfw== X-Gm-Message-State: AOAM532hWT3wjQE7i4eX0VeNuoS5OA3lJ188542Otb3y18dXA+vwRBFn N72F6pfK57SLJ5mAnYQGYUnjf7eFch5wdQ== X-Google-Smtp-Source: ABdhPJyeLE5Yh9ohxNi6QSpU1GpLggVMLlzYWXAWEOcfxVgWdXgdPEc3ENKHv4X4UahEDbTnj3BBuQ== X-Received: by 2002:a05:622a:44:: with SMTP id y4mr32594657qtw.258.1621945762873; Tue, 25 May 2021 05:29:22 -0700 (PDT) Received: from [192.168.1.4] ([177.194.37.86]) by smtp.gmail.com with ESMTPSA id r16sm12142959qtx.36.2021.05.25.05.29.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 May 2021 05:29:22 -0700 (PDT) Subject: Re: [PATCH 3/3] Misc: Add and the cstack_* family of functions To: Paul Eggert Cc: Bruno Haible , Florian Weimer , libc-alpha@sourceware.org References: <73724441.XAIsEQcG03@omega> <146fa4f0-ea19-fdc4-a05c-74008bb4ab5f@linaro.org> From: Adhemerval Zanella Message-ID: Date: Tue, 25 May 2021 09:29:20 -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.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: Tue, 25 May 2021 12:29:24 -0000 On 24/05/2021 20:41, Paul Eggert wrote: > On 5/24/21 12:11 PM, Adhemerval Zanella via Libc-alpha wrote: > >> If this is really a requirement, I think the best options would be to add >> an extra flag to opt-in. > > Opt-in works for me. Although the GNU apps I help maintain typically don't have nested functions, nested functions are a longstanding GNU C feature and are a good thing to have when you need them. > > Part of the issue here (in case this isn't clear) is that we might want to have a Gnulib version (or even just a copy) of cstack_* to help port GNU apps to other platforms. On these other platforms, mmap might not be the right way to make a stack executable (or might not be needed). I imagine that it'd be better to have this implementation detail done by the cstack_* implementation, than to have each nested-function-using app port this detail by hand. > >> The cstack_t is basically another heap object and I think it should be >> handled as such. > > I hope that "handled as such" doesn't mean "the user must always manually free it". That is, even if the cstack_t object is on the heap, surely it'd be more convenient for cstack_* users if the object's storage is automatically reclaimed when a thread exits and the object is no longer needed. The problem is how we go to tie the object lifetime with the thread. Because if the idea is to provide a different stack, I think extending the pthread_attr_t with a size and a flag is way more straightforward than this cstack_t functions. Something like: pthread_attr_t attr; pthread_attr_init (&attr); pthread_attr_setalternatestack_np (262144, PTHREAD_ATTR_NOBOTTOMGUARD); In this manner the pthread_create will be responsible to allocate and deallocate it (on execution ending, pthread_exit, or pthread_cancel). The issue is how will it would mingle with current pthread_attr stack functions, but I think the functionality your are proposing also has the same issue.