Re: Proposed roadmap to 1.0

[Rich Felker <dalias@aerifal.cx>]

On Thu, Jul 25, 2013 at 09:25:39AM +0200, Daniel Cegiełka wrote:
> 2013/7/24 Rich Felker <dalias@aerifal.cx>:
> 
> >
> > That was my question about the whole affinity system in general. My
> > view is that it's stupid micro-management of scheduling that should be
> > done by the kernel, and that if the kernel's not doing a good enough
> > job of managing which cpu a task runs on, the kernel scheduler should
> > be fixed rather than adding hacks in apps.
> 
> Not always. Sometimes the kernel scheduler isn't the solution and you
> care about isolating applications from the kernel/os. How do you do it
> without this feature?
> 
> http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html

It's a nice article and I don't have data to argue with its assessment
of the current bottlenecks, but I disagree with the philosophy that
the solution is to bypass the kernel, in much the same way that I
disagree with the philosophy (of APR, glib, gnulib, etc.) that when
the libc is broken you should bypass the libc. My philosophy is that
if the libc is broken, you should fix the libc, and if the kernel is
broken (which it is, in many ways, especially when it comes to having
too much bloated abstraction in the wrong places, not enough in the
right places, and way too much need for synchronization), then you
should fix the kernel. Admittedly that's not an easy task, and I
should probably shut up until/unless I'm willing to do it.

> musl is a very good candidate for use in HPC, so this functionality
> would be very valuable.

I don't disagree with that. Despite my dislike for the whole affinity
system, I've deemed it important enough to be a big 1.0 roadmap item.
:-)

Rich