From: Rich Felker <dalias@libc.org>
To: Hydro Flask <hydroflask@yqxmail.com>,
Carlos O'Donell <carlos@redhat.com>,
Florian Weimer <fweimer@redhat.com>,
musl@lists.openwall.com
Subject: Re: [musl] Idea: futex() system call entry point
Date: Fri, 17 Jul 2020 17:19:37 -0400 [thread overview]
Message-ID: <20200717211933.GI14669@brightrain.aerifal.cx> (raw)
In-Reply-To: <20200717211050.GB3210874@port70.net>
On Fri, Jul 17, 2020 at 11:10:50PM +0200, Szabolcs Nagy wrote:
> * 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.
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
next prev parent reply other threads:[~2020-07-17 21:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-17 5:51 Hydro Flask
2020-07-17 6:10 ` Florian Weimer
2020-07-17 6:29 ` Hydro Flask
2020-07-17 9:21 ` Szabolcs Nagy
2020-07-17 14:43 ` Carlos O'Donell
2020-07-17 18:57 ` Hydro Flask
2020-07-17 21:10 ` Szabolcs Nagy
2020-07-17 21:19 ` Rich Felker [this message]
2020-07-17 21:27 ` Carlos O'Donell
2020-07-17 21:37 ` Hydro Flask
2020-07-17 23:30 ` Rich Felker
2020-07-18 1:21 ` Hydro Flask
2020-07-18 7:56 ` Szabolcs Nagy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200717211933.GI14669@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=carlos@redhat.com \
--cc=fweimer@redhat.com \
--cc=hydroflask@yqxmail.com \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).