[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150305042354.GM23507@brightrain.aerifal.cx>
Date: Wed, 4 Mar 2015 23:23:54 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: MUSL Feature Detection
On Wed, Mar 04, 2015 at 12:54:58PM -0800, William Ahern wrote:
> I'm familiar with the policy that MUSL is not interested in adding version
> macros, etc. I mostly agree with the policy, however there are some corner
> cases where it's problematic.
>
> I maintain a Lua bindings library to Unix APIs
>
> http://25thandclement.com/~william/projects/lunix.html
Thanks for the background. I missed this in replying to your other
message thread.
> Unlike the most commonly used module, luaposix, my module tries to be as
> thread-safe as possible. (It also supports "portable" but non-POSIX
> interfaces.) That means using all the re-entrant versions of functions if
> available. But some functions don't have re-entrant versions, such as
> strsignal. In those cases I try to synthesize a safe version if possible and
> practical, such as using sys_siglist if available.
FYI, musl's strerror and strsignal are always thread-safe. They
return immutable strings which are valid for the entire lifetime of
the program.
> Knowing whether an interface is thread-safe requires me inspecting the code
> and basically documenting my findings inside the source code with
> conditionals.
Thread-safety for all standard functions is documented by the
standards. All functions defined in POSIX are thread-safe except those
in the table in XSH 2.9.1:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09_01
C11 also specifies which functions are exempt from the requirement not
to have data races, but there does not seem to be any official unified
table; you have to look locally at the documentation for each.
At some point in the future, musl's documentation will specify which
non-standard functions are guaranteed to be thread-safe and which
additional standard functions, beyond those required to be
thread-safe, are guaranteed to be thread-safe in musl. I'm hoping to
make progress on this documentation by the time of the 1.2.0 release.
> I could _also_ do run-time checks, but that's more susceptible
> to false negatives, and so I think it would only make sense to do that as a
> back-stop. (Compile-time checks won't work for cross-compiling).
I don't think run-time checks are practical to deduce thread-safety.
It could easily require months or years of hammering on an interface
to demonstrate it non-thread-safe, and similar time scales to achieve
reasonable certainty that a function is thread-safe.
> The vast majority of people don't pay attention to obscure thread-safety
> issues, especially because the most popular platforms like Linux/glibc and
> Solaris do a pretty decent job of implementing APIs in a thread-safe manner
> (e.g. getenv, strsignal). This lack of interest is especially true in the
> context of a library, and doubly so of a scripting module, where people just
> assume the mode and the dependencies do the right thing, assuming they
> bother worrying about it in the first place.
>
> So you can see I'm stuck between a rock and a hard place. MUSL is probably
> safe in most regards. It doesn't even do localization, so strsignal is safe.
It does, and the localization is thread-safe. Both hard-coded English
message strings and the translated messages (it any) are immutable.
> But I have no easy way to _know_ that I'm building against MUSL without the
> person compiling the module knowingly and explicitly changing the build
> configuration.
>
> So, is there any sort of sanctioned way to detect MUSL at all, version or no
> version? Is there any interest in supporting any kind of feature detection,
> such as an API that communicates implementation choices wrt unspecified and
> undefined behavior.
If we make any information available for programmatic use, I would
like to coordinate this with at least one other libc implementation
(which would probably be glibc, but BSDs are welcome to participate
too). That way it becomes something of a cross-platform convention
rather than our own local quirk.
Rich
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.
