Date: Sat, 14 Jul 2012 12:05:15 -0700 From: Isaac Dunham <idunham@...abit.com> To: musl@...ts.openwall.com Subject: Re: Draft: musl promo materials On Fri, 13 Jul 2012 19:30:52 -0400 Rich Felker <dalias@...ifal.cx> wrote: > Updated version based on some comments.. I think the list is getting > long enough that it would possibly make sense to reorder/trim it for > the intended target audience in some usages, and only include the full > thing on the website. > > Rich > > > ---------------------------------------------------------------------- > > Consistent quality and implementation behavior from tiny embedded > systems to full servers. > > Minimal machine-specific code, meaning less chance of breakage on > minority architectures and better success with "write once run > everywhere" development. One criticism I've heard (not saying I agree!) is that you lose performance with musl thanks to most functions being in C... > Extremely efficient static and dynamic linking support, yielding small > binaries and minimal startup overhead. > > Realtime-quality robustness. No unnecessary dynamic allocation. No > unrecoverable late failures. No lazy binding or lazy allocation. > This reminded me about _XOPEN_REALTIME: "This Option Group consists of the set of the following options from within POSIX.1-2008 (see Options ): _POSIX_FSYNC _POSIX_MEMLOCK _POSIX_MEMLOCK_RANGE _POSIX_MESSAGE_PASSING _POSIX_PRIORITIZED_IO _POSIX_PRIORITY_SCHEDULING _POSIX_SHARED_MEMORY_OBJECTS _POSIX_SYNCHRONIZED_IO " Of these, the MEMLOCK ones are the only ones defined yet. It seems _POSIX_FSYNC is supported, but not advertised. The other 4 are not defined yet; what's musl's support for them? I'm curious how far from complete _XOPEN_REALTIME support musl is. X/Open also defines the Advanced Realtime, Realtime Threads, and Advanced Realtime Threads options. > MIT license. > > Full math library with a focus on correctness. Exact and > correctly rounded conversion between binary floating point and decimal > strings. > > Reentrancy, thread-safety, and async-signal safety well beyond the > requirements of POSIX. Even snprintf and dprintf are fully reentrant > and async-signal-safe. > > Highly resource-efficient POSIX threads implementation, making > multi-threaded application design viable even for memory-constrained > systems. > > Simple source code and source tree layout, so it's easy to customize > or track down the cause of unexpected behavior or bugs, or simply > learn how the library works. Other than the mention of realtime when no proper realtime support is advertised in the headers, seems pretty good.
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.