>Felix Schulte writes:
>> On 6/25/06, Casper.Dik at sun.com <Casper.Dik at sun.com> wrote:
>> > This seems wrong; personally I think we should rip out any replacement
>> > for system libraries; such duplication leads to more code which needs
>> > to be maintained.  This includes replacements for <stdio.h>.
>> There would be no need to replace it if the stdio implementation in
>> Solaris would be sane, however since it sucks a faster, non-sucking
>> replacement would be cool.
>
>In that case, the right answer is to remove the "sucking" part of the
>Solaris stdio.  Since stdio is part of Open Solaris, this is doable.

Quite; replacing "sucking" things with "non sucking functional duplication"
is broken and should not be allowed.  Our architecture committees have
generally frowned upon such changes.  In general, such ARC cases
would be rejected with a firm "back to the drawing board".

I can give you one example why this is bad; it's a kernel example,
but it's pertinent, nonetheless.

Prior to Solaris 2.4 the kernel memory allocator sucked.  Parts of the
system sidestepped this by allocating through the kernel allocator
but freeing to local freelists "so they could allocate faster".

In Solaris 2.4 Jeff Bonwick fixed the kernel memory allocator and made it
scale.  We've been cleaning up private implementations ever since.

And in case you're interested, the one I fixed in Solaris 9 (auditing)
stopped scaling at a single CPU.  It was just a plain, simple, freelist.

This taught me that it is better to use the standard, sub optimal,
implementation and lobby for its improvment over implementing your
own "improvement".  That's because this year's optimization over the
standard algorithm is next year's pessimisation because someone just
improved the default.

>I agree with Casper that creating your own stdio because you don't
>like the one in Open Solaris is architecturally infeasible.  We cannot
>just allow parts of the system that we think are broken to rot in
>place.  We (the community, all of us collectively) own this software,
>and we have a responsibility to maintain it properly.

>Forking off and restarting is not proper maintenance.

No, and it doubles maintenance costs.

>That doesn't make it any less awful.

It prevents sudden explosions, but it's still bad.

Casper

Reply via email to