mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Hydro Flask <hydroflask@yqxmail.com>
To: musl@lists.openwall.com
Cc: Carlos O'Donell <carlos@redhat.com>, Florian Weimer <fweimer@redhat.com>
Subject: Re: [musl] Idea: futex() system call entry point
Date: Fri, 17 Jul 2020 14:37:27 -0700	[thread overview]
Message-ID: <449cc77dc2bc153de7a2633ee8613b42@yqxmail.com> (raw)
In-Reply-To: <20200717211933.GI14669@brightrain.aerifal.cx>

On 2020-07-17 14:19, Rich Felker wrote:
> 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]:
>> > 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.

I didn't realize this discussion was more complex. Non-Linux/Glibc is 
not my use case so I would have proposed "musl_futex()" to make things 
move quicker but not if adding non-standard calls is something Linux 
libcs avoid without consensus.

Maybe a less complex suggestion is to expose a syscall_cp() function, so 
you can get cancellation point functionality for any system call. I 
actually quite like that option. How does that sound?

  parent reply	other threads:[~2020-07-17 21:37 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
2020-07-17 21:27               ` Carlos O'Donell
2020-07-17 21:37               ` Hydro Flask [this message]
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=449cc77dc2bc153de7a2633ee8613b42@yqxmail.com \
    --to=hydroflask@yqxmail.com \
    --cc=carlos@redhat.com \
    --cc=fweimer@redhat.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).