Re: [musl] Idea: futex() system call entry point

[Szabolcs Nagy <nsz@port70.net>]

* Hydro Flask <hydroflask@yqxmail.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@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.

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.