[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 17 Jul 2020 18:21:27 -0700
From: Hydro Flask <hydroflask@...mail.com>
To: musl@...ts.openwall.com
Cc: Carlos O'Donell <carlos@...hat.com>, Florian Weimer <fweimer@...hat.com>
Subject: Re: Idea: futex() system call entry point
On 2020-07-17 16:30, Rich Felker wrote:
> On Fri, Jul 17, 2020 at 02:37:27PM -0700, Hydro Flask wrote:
>> 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?
Oh I hadn't thought of that. That's actually a pretty good short-term
solution. So you're saying:
int fuxex_wait(int *uaddr, int val, const struct timespec *timeout)
{
int old, ret;
/* pthread_setcanceltype() automatically calls
pthread_testcancel() if async is enabled */
ret = pthread_setcanceltype(PTHREAD_CANCEL_ASYNCHRONOUS,
&old);
if (ret) {
errno = ret;
ret = -1;
}
ret = syscall(SYS_futex, uaddr, FUTEX_WAIT, val, timeout);
old = pthread_setcanceltype(old, &old);
if (old) abort();
return ret;
}
I think you're right that even if the futex call succeeds, it's fine to
cancel since it does not mutate any meaningful observable state. I think
that should satisfy all my requirements when doing this on musl.
pthread_testcancel/pthread_setcanceltype should be AS-safe in musl if
cancellation is disabled or the interrupted code is AC-safe.
That should likely also work in other libcs assuming a sane
implementation of all the required functions involved. Thank you
Hydro
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.
