[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <449cc77dc2bc153de7a2633ee8613b42@yqxmail.com>
Date: Fri, 17 Jul 2020 14:37: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 14:19, Rich Felker wrote:
> On Fri, Jul 17, 2020 at 11:10:50PM +0200, Szabolcs Nagy wrote:
>> * Hydro Flask <hydroflask@...mail.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?
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.
