[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7a8de0d4-d9f7-6ab2-1aec-713597b47ca8@redhat.com>
Date: Fri, 17 Jul 2020 10:43:56 -0400
From: Carlos O'Donell <carlos@...hat.com>
To: Hydro Flask <hydroflask@...mail.com>, Florian Weimer
<fweimer@...hat.com>, musl@...ts.openwall.com
Subject: Re: Idea: futex() system call entry point
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.
>> This same API is used in both synchronous and asynchronous contexts, which
>> is why it must be a cancellation point.
--
Cheers,
Carlos.
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.
