|
Message-ID: <95e258a1-e376-1d2f-2533-f100b37b1e7b@redhat.com> Date: Fri, 17 Jul 2020 17:27:17 -0400 From: Carlos O'Donell <carlos@...hat.com> To: musl@...ts.openwall.com, Rich Felker <dalias@...c.org>, Hydro Flask <hydroflask@...mail.com>, Florian Weimer <fweimer@...hat.com> Subject: Re: Idea: futex() system call entry point On 7/17/20 5:19 PM, Rich Felker wrote: > On Fri, Jul 17, 2020 at 11:10:50PM +0200, Szabolcs Nagy wrote: >> * Hydro Flask <hydroflask@...mail.com> [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 <hydroflask@...mail.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. >> >> 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. Likewise. -- Cheers, Carlos.
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.