[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGyQ6gzOhnNt5mc5j_CXxzhOk2ioa4WuqM8UgSR6Km64dT+PSw@mail.gmail.com>
Date: Wed, 3 Jun 2020 22:35:11 -0700
From: Siva Chandra <sivachandra@...gle.com>
To: libc-coord@...ts.openwall.com
Cc: Petr Hosek <phosek@...gle.com>
Subject: Re: Macro-based advertisement of libc extensions
We (LLVM libc developers) are interested in this general topic as we
are considering adding extensions to LLVM libc around the mutex types
from the C standard header threads.h. Before I go into the details of
what exactly we want to add, I have some inline comments on the main
proposal in this thread.
On Wed, Apr 22, 2020 at 10:38 AM Rich Felker <dalias@...c.org> wrote:
>
> This is proposal I've mentioned in various settings for a while, but
> that should be discussed more thoroughly in a proper setting, and
> libc-coord is the setting I'd been looking to do it in.
>
>
> Proposal:
>
> I want to establish a common convention, with participation by
> multiple (Linux and non-Linux, ideally BSDs and others too) libc
> implementations, for macros defined by the implementation to advertise
> nonstandard extensions offered for use by applications.
>
> These should be modeled on the POSIX macros defined in unistd.h, like
> _POSIX_MONOTONIC_CLOCK, _POSIX_TIMERS, _POSIX_SEMAPHORES, etc. and
> should use a dedicated part of the reserved namespace like _EXT_* or
> similar. Possibly this should include the semantics for definition
> with a value of 0 ("supported for compilation and might or might not
> be supported at runtime"), which may make sense for implementations
> with different profiles or that only offer certain functionality
> contingent on a kernel that supports it, etc. If that option is taken,
> there could be corresponding sysconf (e.g. _SC_EXT_*) macros to query
> availability at runtime, or a separate interface so as not to overload
> sysconf.
Unless there is benefit in overloading existing conventions and naming
schemes, I would prefer having a new naming scheme which reflects the
fact that it has been added after sign-off on the libc-coord list.
Perhaps something like _COORD_<...> which reflects that it has been
signed-off by libc-coord while not being any more verbose than
_POSIX_<...>.
> Implementation:
>
> I'm not particular about how this is done, but my leaning would be
> either putting the macros in an existing standard header (preference:
> unistd.h) or defining a single macro via a standard header that
> advertises the presence of a second header they're all provided by.
> Another option might be grouping them by functionality (i.e. stdio
> extensions are advertised in stdio.h).
I prefer the latter option of grouping them by functionality.
> Open questons:
>
> What degree of compatibility do "equivalent" extensions need to be
> advertised as the same? While I'd like part of the outcome of this
> effort to be standardization of common extensions that are deemed to
> be worth standardization (upstreaming in C or POSIX), I'm not
> proposing running a parallel extra-standard standards organization.
I would view this as an arrangement of convenience and not as an
extra-standard effort/organization. For one, this effort can serve as
a staging area for proposals to the official standards' committees.
Also, maintainers of different libcs can sign-off on a certain
extension, but can choose not to provide that extension in their libc.
They would of course have to sign-off on what exactly a certain
extension is.
> For extensions which already have multiple implementations, I think
> the baseline macro should roughly mean "whatever is common between
> historical implementations". If some implementations have additional
> features (for example, accepting a null pointer) they can define in
> addition to _EXT_FOO macros that advertise these additional properties
> (in that example, _EXT_FOO_ACCEPTS_NULL).
I would expect that all libcs have to agree on the set of extension
macros. For example, if we libc-coord signs off only about the
_EXT_FOO macro, but some libc provides _EXT_FOO_ACCEPTS_NULL without a
sign-off from libc-coord, then that should amount to name pollution.
So yes, all the extensions we accept/sign-off on have to be published
and specified just like a formal standard would do. Requiring a
precise specification might seem like a hard barrier, but without it,
different libcs can potentially end up with differing semantics.
> Where should common names be published?
Maybe a libc-coord github project?
> A minimal version of that would just be posting
> intent to this list and not having sustained well-motivated objection
> to it. But maybe something more official/searchable/etc. makes sense.
A github project would give us a formal way of doing all of these.
Coming back to mutex related extensions we would like to add to
LLVM-libc: The standard specifies just one type mtx_t for recursive as
well as non-recursive mutexes. We have observed that this leads to
non-trivial costs in certain applications which only need
non-recursive mutexes (because of the additional branches in the
locking/unlocking functions). So, we would like to add two separate
mutex types, one for non-recursive mutexes, and another for recursive
mutexes. It seems a little premature to make a formal proposal about
this as we are still discussing how to make proposals and add
extensions. But, roughly, we would like the extension to be modelled
like the C++ std::mutex and std::recursive_mutex classes (and may be
even std::timed_mutex and friends.)
Thanks,
Siva Chandra
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.
