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.3 required=5.0 tests=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 1697 invoked from network); 17 Jul 2020 21:11:06 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 17 Jul 2020 21:11:06 -0000 Received: (qmail 28424 invoked by uid 550); 17 Jul 2020 21:11:03 -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 28404 invoked from network); 17 Jul 2020 21:11:03 -0000 Date: Fri, 17 Jul 2020 23:10:50 +0200 From: Szabolcs Nagy To: Hydro Flask Cc: Carlos O'Donell , Florian Weimer , musl@lists.openwall.com Message-ID: <20200717211050.GB3210874@port70.net> Mail-Followup-To: Hydro Flask , Carlos O'Donell , Florian Weimer , musl@lists.openwall.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> <03e28c2e6beb406c3a1ce3bfa99c67eb@yqxmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03e28c2e6beb406c3a1ce3bfa99c67eb@yqxmail.com> Subject: Re: [musl] Idea: futex() system call entry point * Hydro Flask [2020-07-17 11:57:36 -0700]: > On 2020-07-17 07:43, Carlos O'Donell wrote: > > 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. > > 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. it's possible to do this, but it's a rare requirement. futex is not a nice syscall to expose in c. currently there is disagreement about how to expose it: directly the linux api (which is variadic and not very typesafe) or separate calls for the useful operations (futex_wait, futex_wake, etc but the exact c api is less clear then). because of new time_t abi on 32bit targets, the timeout argument to futex is another reason to expose it in c instead of allowing users to use it via syscall (if they use the libc timespec type with the raw syscall that can be broken). in any case it's better to discuss this on libc-alpha since musl and glibc must expose the same api for it to be useful and it is harder to get this into glibc.