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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 31864 invoked from network); 17 Jul 2020 06:30:13 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 17 Jul 2020 06:30:13 -0000 Received: (qmail 29870 invoked by uid 550); 17 Jul 2020 06:30:08 -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 29852 invoked from network); 17 Jul 2020 06:30:08 -0000 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yqxmail.com; s=dkim; t=1594967394; bh=RKK30UycMXjGfJ2CeFEnvAAV2AzL7COgw7r5Rt88+W4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=KJHPEZVGqwDXMYGtcNObCU7OQN8Pn5F2YqhJfLwfAVAFj3bboC2K0UDXfEuMvaR4q JQGBTJgML1fQVqaSS0WlchTUuRp8Av3G6Nk+uT/idG1m/jz3DBeGystDDyObUtnmej uiKgm3cLWADPuwaAlWXChAVd6/GN1g+X5p7Fw/Koq/Mb/FnCMAHdfDzdmNJTchhcqc AlHHtEDqUUBKPWK6GHuC41o97+tdu3sS73BG++0XX0xgJE+noYOWAldOnaTV0tslWE tPVOFnO40x7F2k6a6HMlHWGTpiLU0Ovu6GHTOpG168oFXO+JMVNElZEGg4xTd+22b2 /TK6xx8p7BbDg== Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 16 Jul 2020 23:29:53 -0700 From: Hydro Flask To: Florian Weimer Cc: musl@lists.openwall.com In-Reply-To: <87pn8uwu18.fsf@oldenburg2.str.redhat.com> References: <04c05d65470b5c94808481eaf724cc5d@yqxmail.com> <87pn8uwu18.fsf@oldenburg2.str.redhat.com> Message-ID: <4095a8a7f75becee9bcfc71024e43802@yqxmail.com> Subject: Re: [musl] Idea: futex() system call entry point 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. This same API is used in both synchronous and asynchronous contexts, which is why it must be a cancellation point.