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=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL
	autolearn=ham autolearn_force=no version=3.4.4
Received: (qmail 17699 invoked from network); 17 Jul 2020 18:57:51 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 17 Jul 2020 18:57:51 -0000
Received: (qmail 11444 invoked by uid 550); 17 Jul 2020 18:57:49 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 11426 invoked from network); 17 Jul 2020 18:57:48 -0000
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yqxmail.com; s=dkim;
	t=1595012256; bh=PQ/dsGLu3oTS2NT9tV0TXLD8kjEKrWf4mPqmvA0ZRIg=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=IJvqIKGt0Ru047J5wJmVp7tksFoU0Ib41q3GkDoZ04OGWv9xSFWWwAmEE6YBCAabI
	 wAeiH75/QhaSTOEGHHrdSehihvGyDAiiOf5Srkqnh6mnBaRcsW5wRI01Z7AlNyL3ar
	 fEwt1BQKrCPMKEnq+J/D4D4oenusOMVLLQ9YNlIeRIpNssaU/LxlEk8/2f9XW48d+9
	 t7TYqS5qCRIAlqV0uHXj8+A8Zh4V4ofQ3xS6leCDIJQm5gqqlXERonO7YJpzYoiU0X
	 GX8uTN+CSFRtJY2x5EcPUMFp8Di36QENtxn4rbzHd/4UnWWt6AQTNheh3TZhv0APgt
	 n2NKdJbmAl5Fw==
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Fri, 17 Jul 2020 11:57:36 -0700
From: Hydro Flask <hydroflask@yqxmail.com>
To: Carlos O'Donell <carlos@redhat.com>
Cc: Florian Weimer <fweimer@redhat.com>, musl@lists.openwall.com
In-Reply-To: <7a8de0d4-d9f7-6ab2-1aec-713597b47ca8@redhat.com>
References: <04c05d65470b5c94808481eaf724cc5d@yqxmail.com>
 <87pn8uwu18.fsf@oldenburg2.str.redhat.com>
 <4095a8a7f75becee9bcfc71024e43802@yqxmail.com>
 <20200717092111.GA3210874@port70.net>
 <7a8de0d4-d9f7-6ab2-1aec-713597b47ca8@redhat.com>
Message-ID: <03e28c2e6beb406c3a1ce3bfa99c67eb@yqxmail.com>
Subject: Re: [musl] Idea: futex() system call entry point

On 2020-07-17 07:43, Carlos O'Donell wrote:
> On 7/17/20 5:21 AM, Szabolcs Nagy wrote:
>> * Hydro Flask <hydroflask@yqxmail.com> [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.

There is a section in POSIX that covers exactly this, read the 
"Application Usage" section of 
https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_setcancelstate.html

In general the user should ensure that cancellation is disabled one way 
or another when the call is called from the signal handler, or that the 
call is being done in a AC-safe region. There are a variety of ways to 
do this as discussed in POSIX.