[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 17 Jul 2020 11:57:36 -0700
From: Hydro Flask <hydroflask@...mail.com>
To: Carlos O'Donell <carlos@...hat.com>
Cc: Florian Weimer <fweimer@...hat.com>, musl@...ts.openwall.com
Subject: Re: Idea: futex() system call entry point
On 2020-07-17 07:43, Carlos O'Donell wrote:
> On 7/17/20 5:21 AM, Szabolcs Nagy wrote:
>> * Hydro Flask <hydroflask@...mail.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.
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.
