mailing list of musl libc
 help / color / Atom feed
* [musl] Idea: futex() system call entry point
@ 2020-07-17  5:51 Hydro Flask
  2020-07-17  6:10 ` Florian Weimer
  0 siblings, 1 reply; 13+ messages in thread
From: Hydro Flask @ 2020-07-17  5:51 UTC (permalink / raw)
  To: musl

Hello,

I have a project that implements an API that must be AS-safe. This is a 
blocking API, so currently the only option I have to implement the 
blocking behavior is select()/read() and similar FD-based calls.

Using FDs to implement synchronization is okay but if there are very 
many threads then FD space would get exhausted (usually max 1024 FDs). 
It would be nice to use pthread_cond_wait() but that is not AS-safe 
according to POSIX.

Had the idea of using futex() but my other constraint is that the 
blocking call must also be a cancellation point. Currently calling the 
futex system call through syscall() won't work and there is no way to 
implement cancellation on top of syscall() in a portable way since 
cancellation is implementation defined.

So what if Linux libcs (and potentially others) started exposing futex() 
directly as a function call? It would need these properties to be 
useful:

* AS-safe
* cancellation point

I saw that Rich Felker already proposed this many years ago but it seems 
it never came to fruition: 
https://sourceware.org/bugzilla/show_bug.cgi?id=9712#c8

What do you think about my idea?

Hydro

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [musl] Idea: futex() system call entry point
  2020-07-17  5:51 [musl] Idea: futex() system call entry point Hydro Flask
@ 2020-07-17  6:10 ` Florian Weimer
  2020-07-17  6:29   ` Hydro Flask
  0 siblings, 1 reply; 13+ messages in thread
From: Florian Weimer @ 2020-07-17  6:10 UTC (permalink / raw)
  To: Hydro Flask; +Cc: musl

* 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?

Thanks,
Florian


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [musl] Idea: futex() system call entry point
  2020-07-17  6:10 ` Florian Weimer
@ 2020-07-17  6:29   ` Hydro Flask
  2020-07-17  9:21     ` Szabolcs Nagy
  0 siblings, 1 reply; 13+ messages in thread
From: Hydro Flask @ 2020-07-17  6:29 UTC (permalink / raw)
  To: Florian Weimer; +Cc: musl

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.

This same API is used in both synchronous and asynchronous contexts, 
which is why it must be a cancellation point.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [musl] Idea: futex() system call entry point
  2020-07-17  6:29   ` Hydro Flask
@ 2020-07-17  9:21     ` Szabolcs Nagy
  2020-07-17 14:43       ` Carlos O'Donell
  0 siblings, 1 reply; 13+ messages in thread
From: Szabolcs Nagy @ 2020-07-17  9:21 UTC (permalink / raw)
  To: Hydro Flask; +Cc: Florian Weimer, musl

* Hydro Flask <hydroflask@yqxmail.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?

> 
> This same API is used in both synchronous and asynchronous contexts, which
> is why it must be a cancellation point.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [musl] Idea: futex() system call entry point
  2020-07-17  9:21     ` Szabolcs Nagy
@ 2020-07-17 14:43       ` Carlos O'Donell
  2020-07-17 18:57         ` Hydro Flask
  0 siblings, 1 reply; 13+ messages in thread
From: Carlos O'Donell @ 2020-07-17 14:43 UTC (permalink / raw)
  To: Hydro Flask, Florian Weimer, musl

On 7/17/20 5:21 AM, Szabolcs Nagy wrote:
> * Hydro Flask <hydroflask@yqxmail.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.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [musl] Idea: futex() system call entry point
  2020-07-17 14:43       ` Carlos O'Donell
@ 2020-07-17 18:57         ` Hydro Flask
  2020-07-17 21:10           ` Szabolcs Nagy
  0 siblings, 1 reply; 13+ messages in thread
From: Hydro Flask @ 2020-07-17 18:57 UTC (permalink / raw)
  To: Carlos O'Donell; +Cc: Florian Weimer, musl

On 2020-07-17 07:43, Carlos O'Donell wrote:
> On 7/17/20 5:21 AM, Szabolcs Nagy wrote:
>> * Hydro Flask <hydroflask@yqxmail.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.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [musl] Idea: futex() system call entry point
  2020-07-17 18:57         ` Hydro Flask
@ 2020-07-17 21:10           ` Szabolcs Nagy
  2020-07-17 21:19             ` Rich Felker
  0 siblings, 1 reply; 13+ messages in thread
From: Szabolcs Nagy @ 2020-07-17 21:10 UTC (permalink / raw)
  To: Hydro Flask; +Cc: Carlos O'Donell, Florian Weimer, musl

* Hydro Flask <hydroflask@yqxmail.com> [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 <hydroflask@yqxmail.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.

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.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [musl] Idea: futex() system call entry point
  2020-07-17 21:10           ` Szabolcs Nagy
@ 2020-07-17 21:19             ` Rich Felker
  2020-07-17 21:27               ` Carlos O'Donell
  2020-07-17 21:37               ` Hydro Flask
  0 siblings, 2 replies; 13+ messages in thread
From: Rich Felker @ 2020-07-17 21:19 UTC (permalink / raw)
  To: Hydro Flask, Carlos O'Donell, Florian Weimer, musl

On Fri, Jul 17, 2020 at 11:10:50PM +0200, Szabolcs Nagy wrote:
> * Hydro Flask <hydroflask@yqxmail.com> [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 <hydroflask@yqxmail.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.
> 
> 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.

Rich

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [musl] Idea: futex() system call entry point
  2020-07-17 21:19             ` Rich Felker
@ 2020-07-17 21:27               ` Carlos O'Donell
  2020-07-17 21:37               ` Hydro Flask
  1 sibling, 0 replies; 13+ messages in thread
From: Carlos O'Donell @ 2020-07-17 21:27 UTC (permalink / raw)
  To: musl, Rich Felker, Hydro Flask, Florian Weimer

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 <hydroflask@yqxmail.com> [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 <hydroflask@yqxmail.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.
>>
>> 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.

Likewise.

-- 
Cheers,
Carlos.


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [musl] Idea: futex() system call entry point
  2020-07-17 21:19             ` Rich Felker
  2020-07-17 21:27               ` Carlos O'Donell
@ 2020-07-17 21:37               ` Hydro Flask
  2020-07-17 23:30                 ` Rich Felker
  1 sibling, 1 reply; 13+ messages in thread
From: Hydro Flask @ 2020-07-17 21:37 UTC (permalink / raw)
  To: musl; +Cc: Carlos O'Donell, Florian Weimer

On 2020-07-17 14:19, Rich Felker wrote:
> On Fri, Jul 17, 2020 at 11:10:50PM +0200, Szabolcs Nagy wrote:
>> * Hydro Flask <hydroflask@yqxmail.com> [2020-07-17 11:57:36 -0700]:
>> > 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.

I didn't realize this discussion was more complex. Non-Linux/Glibc is 
not my use case so I would have proposed "musl_futex()" to make things 
move quicker but not if adding non-standard calls is something Linux 
libcs avoid without consensus.

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?

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [musl] Idea: futex() system call entry point
  2020-07-17 21:37               ` Hydro Flask
@ 2020-07-17 23:30                 ` Rich Felker
  2020-07-18  1:21                   ` Hydro Flask
  0 siblings, 1 reply; 13+ messages in thread
From: Rich Felker @ 2020-07-17 23:30 UTC (permalink / raw)
  To: Hydro Flask; +Cc: musl, Carlos O'Donell, Florian Weimer

On Fri, Jul 17, 2020 at 02:37:27PM -0700, Hydro Flask wrote:
> On 2020-07-17 14:19, Rich Felker wrote:
> >On Fri, Jul 17, 2020 at 11:10:50PM +0200, Szabolcs Nagy wrote:
> >>* Hydro Flask <hydroflask@yqxmail.com> [2020-07-17 11:57:36 -0700]:
> >>> 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.
> 
> I didn't realize this discussion was more complex. Non-Linux/Glibc
> is not my use case so I would have proposed "musl_futex()" to make
> things move quicker but not if adding non-standard calls is
> something Linux libcs avoid without consensus.
> 
> 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?

This does not resolve the lack of a proper futex() function, but it
does seem preferable to the hacks proposed above.

Rich

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [musl] Idea: futex() system call entry point
  2020-07-17 23:30                 ` Rich Felker
@ 2020-07-18  1:21                   ` Hydro Flask
  2020-07-18  7:56                     ` Szabolcs Nagy
  0 siblings, 1 reply; 13+ messages in thread
From: Hydro Flask @ 2020-07-18  1:21 UTC (permalink / raw)
  To: musl; +Cc: Carlos O'Donell, Florian Weimer

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [musl] Idea: futex() system call entry point
  2020-07-18  1:21                   ` Hydro Flask
@ 2020-07-18  7:56                     ` Szabolcs Nagy
  0 siblings, 0 replies; 13+ messages in thread
From: Szabolcs Nagy @ 2020-07-18  7:56 UTC (permalink / raw)
  To: Hydro Flask; +Cc: musl, Carlos O'Donell, Florian Weimer

* Hydro Flask <hydroflask@yqxmail.com> [2020-07-17 18:21:27 -0700]:
> 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);

note that passing libc types (timespec)
to raw syscall is broken (at least on
32bit targets, but in general a libc
type may not match kernel types if this
has to be portable to other libcs).

you have to locally create a type that
is known to match the kernel abi on the
targets you care about and translate
between the libc type and that.

>             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

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, back to index

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-17  5:51 [musl] Idea: futex() system call entry point Hydro Flask
2020-07-17  6:10 ` Florian Weimer
2020-07-17  6:29   ` Hydro Flask
2020-07-17  9:21     ` Szabolcs Nagy
2020-07-17 14:43       ` Carlos O'Donell
2020-07-17 18:57         ` Hydro Flask
2020-07-17 21:10           ` Szabolcs Nagy
2020-07-17 21:19             ` Rich Felker
2020-07-17 21:27               ` Carlos O'Donell
2020-07-17 21:37               ` Hydro Flask
2020-07-17 23:30                 ` Rich Felker
2020-07-18  1:21                   ` Hydro Flask
2020-07-18  7:56                     ` Szabolcs Nagy

mailing list of musl libc

Archives are clonable: git clone --mirror http://inbox.vuxu.org/musl

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git