Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 17 Jul 2020 17:27:17 -0400
From: Carlos O'Donell <>
To:, Rich Felker <>,
 Hydro Flask <>, Florian Weimer <>
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 <> [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 <> [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
>>> 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.



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.