From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 21588 invoked from network); 17 Jul 2020 14:44:21 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 17 Jul 2020 14:44:21 -0000 Received: (qmail 28650 invoked by uid 550); 17 Jul 2020 14:44:13 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 28629 invoked from network); 17 Jul 2020 14:44:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1594997041; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3w45mLoDWdUvwvyDJBb8e5mDrXPNBN2H75ezDTG5H48=; b=MvBfmPCX88ARoMhxbzcEx2fnFalygcuURucvOXK+sM/TZnqgz3aNzNqVPsConbATUviGNw Sqy++C1W64dWwf323LApXIaOrtBErSpmE83ofzuysvJfigZMPIz0cjBCpevAAdEaSqWBII d1FptXznjIL32H1HVyyho1Jr66XhVEk= X-MC-Unique: vIcv2CcWN1-WID6yBSq9Ew-1 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=3w45mLoDWdUvwvyDJBb8e5mDrXPNBN2H75ezDTG5H48=; b=WHyGpmzeOY6avU3IH7IhjXexi/XeeecRxL67wB3+Kkc3Y/6rgX1eyifG7lUySBv++5 xK0GR9rYIxqU4GOe4AarnNsZI9OoSU24g+5LHE74ZFMFzIWZp1fgdWPr/FxS6o/9sEjc 6i0kb8Edy3AVecqtM4FwfgZW23H+xVzY1yKW6y/Zosuta5CPaDHIL8QVqOEdbuOEDiAH +CFK+cwt69uHq5Jfpfck8IAnH3dOo/teVXXZVbjuO8VPozRbvHShN8swMohw7IgVEdbz nsu3Jd+9UMhPSRSzjVmihdvIwx8XpmoRa2GzuG5jyliB+gD2fsx1grFc2rAN5FPc9aIm yZow== X-Gm-Message-State: AOAM533wMaZQMUV3azjriaNhYwX2w2HeNzJmeNlqvJ1nCrL2XQWDvE0A gCj8bn/ERdkhF6hIT42jeGS1SJOJMijkTxwdu8fB5rHeDkuF4KGcXp06I8GaTJvGvtdZ03Xvh06 mlzz7mm+XQjIvKvxVNw== X-Received: by 2002:a0c:83c4:: with SMTP id k62mr9354581qva.19.1594997038660; Fri, 17 Jul 2020 07:43:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxQr+/3gsdFXhHSubYxrsxDyfJKeyvkQT1NAAtlByxqbwQyB2c5OkV6aPh2HGyPReY2n4RmlA== X-Received: by 2002:a0c:83c4:: with SMTP id k62mr9354554qva.19.1594997038397; Fri, 17 Jul 2020 07:43:58 -0700 (PDT) To: Hydro Flask , Florian Weimer , musl@lists.openwall.com References: <04c05d65470b5c94808481eaf724cc5d@yqxmail.com> <87pn8uwu18.fsf@oldenburg2.str.redhat.com> <4095a8a7f75becee9bcfc71024e43802@yqxmail.com> <20200717092111.GA3210874@port70.net> From: Carlos O'Donell Organization: Red Hat Message-ID: <7a8de0d4-d9f7-6ab2-1aec-713597b47ca8@redhat.com> Date: Fri, 17 Jul 2020 10:43:56 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200717092111.GA3210874@port70.net> Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [musl] Idea: futex() system call entry point On 7/17/20 5:21 AM, Szabolcs Nagy wrote: > * Hydro Flask [2020-07-16 23:29:53 -0700]: >> On 2020-07-16 23:10, Florian Weimer wrote: >>> * Hydro Flask: >>> >>>> I have a project that implements an API that must be AS-safe. >>> >>>> Had the idea of using futex() but my other constraint is that the >>>> blocking call must also be a cancellation point. >>> >>> Cancellation points in signal handlers lead to asynchronous >>> cancellation. Are you sure that this is what you want? >> >> Yes I am aware of that. The caller is responsible for making sure it is safe >> to call the cancellation point in the signal handler per the recommendations >> in POSIX. > > how does the caller ensure that the interrupted > code is async cancel safe? I would also like to know that :-) Requiring AC-safety in the interrupted code is going to seriously limit what that code can call and do and indirectly what compiler and language implementation can even be used to implement that compiled code. >> This same API is used in both synchronous and asynchronous contexts, which >> is why it must be a cancellation point. -- Cheers, Carlos.