Re: Draft: musl promo materials

[Rich Felker <dalias@aerifal.cx>]

On Sat, Jul 14, 2012 at 12:05:15PM -0700, Isaac Dunham wrote:
> On Fri, 13 Jul 2012 19:30:52 -0400
> Rich Felker <dalias@aerifal.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...

I haven't found that to be the case. When it is, asm can be added if
needed. If you're aware of some operations that are significantly
slower than glibc and believe lack of asm is the problem, please
report them.

> > 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 ):
> [...]
> I'm curious how far from  complete _XOPEN_REALTIME support musl is.

When I refer to realtime-quality, it's a matter of the entire library
having suitable characteristics for realtime use - things like not
crashing from resouce exhaustion, not having gratuitious resource
contention issues, etc. The _XOPEN_REALTIME option is full of extra
functionality that's useful for programming idioms that are commonly
used/taught for realtime programming, which is a separate issue.
Amusingly, some libcs go out of their way to support the latter and
completely fail to support the former, making the latter utterly
useless.

Rich