[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200717233058.GJ14669@brightrain.aerifal.cx>
Date: Fri, 17 Jul 2020 19:30:58 -0400
From: Rich Felker <dalias@...c.org>
To: Hydro Flask <hydroflask@...mail.com>
Cc: musl@...ts.openwall.com, Carlos O'Donell <carlos@...hat.com>,
Florian Weimer <fweimer@...hat.com>
Subject: Re: Idea: futex() system call entry point
On Fri, Jul 17, 2020 at 02:37:27PM -0700, Hydro Flask wrote:
> 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@...mail.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?
In the specific case of futex waits, it's not clear to me that there's
any side effect for which you need to know in the cancellation handler
whether it occurred, so why can't you just enable async cancel around
syscall() and disable it again after?
This does not resolve the lack of a proper futex() function, but it
does seem preferable to the hacks proposed above.
Rich
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.
