|
Message-ID: <75e93ed84f40957c3750fb42c366447b@yqxmail.com> 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.