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 2692 invoked from network); 17 Jul 2020 21:19:53 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 17 Jul 2020 21:19:53 -0000 Received: (qmail 32369 invoked by uid 550); 17 Jul 2020 21:19:50 -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 32351 invoked from network); 17 Jul 2020 21:19:49 -0000 Date: Fri, 17 Jul 2020 17:19:37 -0400 From: Rich Felker To: Hydro Flask , Carlos O'Donell , Florian Weimer , musl@lists.openwall.com Message-ID: <20200717211933.GI14669@brightrain.aerifal.cx> 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> <20200717211050.GB3210874@port70.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200717211050.GB3210874@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Idea: futex() system call entry point On Fri, Jul 17, 2020 at 11:10:50PM +0200, Szabolcs Nagy wrote: > * 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. CC'ing libc-coord would also be appropriate for this, I think, even if it is Linux-only and not relevant to the BSD etc folks there. I do want to expose futex function but I don't want to end up with something gratuitously incompatible/conflicting with what glibc ends up doing. Rich