KSE

Several people have asked me about todays removal of the
asynchronous system call support. (AKA KSE).

The answer is a little complicated.


In 1998 about 15 people regularly got together in Foster City,
in the offices of Whistle Communications (RIP) and argued over
a several month several month period about what to do about
threading.  A design emerged, which allowed for several models
of threading to be implemented, including 1:1 and M:N
and even M:1 (if N ==1).

Since no-one was doing this I implemented this in 1999->2001
and it was introduced into 5.0.

Dan Eischen was brave enough to take on the userland side of the M:N
threading and I think neither of us realized how really tricky this 
would become.

In the last few years several things have happened that have
changed the threading landscape, in particular the fact is, that
with it's commanding position, Linux has forced most developers to
abandon threading their applications in a way that is not suitable for 
1:1.

Also "Everybody got Busy". (kids etc).

The the complexity of M:N could not really be overcome
with the resources available. Dan has done a Might Job (TM)
with some help from David Xu, and I tried to keep the kernel
side in order as much as I could, but I think the time has just
come when we must say, that the experiment of M:N threading
is declared to be at an end. It's not that it is an inherently
bad idea, but that we don't have the resources that some
companies that HAVE been able to do it were able to put on the
problem. In the same time the requirement for M:N has reduced.
In 1998 no=one really knew a lot about threaded Unix programs
because there were not a lot of them. As time has gone past
the models that have evolved have moved away from having
thousands of threads in a program, as that was not good on
Linux to having just a few. Given this the extra complexity
needed for M:N seems more and more out of place.

Not all is lost however. The same framework changes that produced
the M:N kernel support were, by design also capable of
supporting 1:1 threading. This is where the world has gone,
and we are perfectly set up to support this. The decisions we took
in 1998 to support both models was good and our words at the time
were in hindsight perfectly correct. I'm sure those who were
there will remember that we said "We'll support several models
and see which works best and when that becomes clear we can
migrate to that model".

The work done by all parties in keeping the two
threading libraries in sync so that their ABIs are compatible
has payed off big-time here. I would especially like to
bring the spot light on several people here:

-----
Dan Eischen.  Despite having a "real life" He did the imppossible
and made the M:N library more reliable than the simpler 1:1 library
for many years.
I'm hoping that Dan doesn't take this as his queue to leave
the project.  I really do know how disheartening is is
to have some part of your life taken out of production.
I hope EVERYONE here takes the time to consider what a great
job Dan has done, looking after not only libc_r but libkse,
and taking the project from basically no threads to fully threaded.
-----
Jeffr and David Xu (and David Mini in the beginning):
Took on the task of making the 1:1 library competitive.
AND KEPT IT COMPATIBLE.
-----
All the developers who allowed us to try.

-----

I think at this moment I will shed a tear for a grand idea,
but look forward to the fact that we can concentrate on getting
every last cycle of every processor, and I am pretty sure
that despite what would appear to have been "wasted time" to some,
It was not and we have learned a hell of a lot. FreeBSD has
not been held up by this as we had the forethought to plan
ahead. The changed landscape has meant that though I think
there were some cases where M:N was needed, these cases are getting
fewer and fewer and FreeBSD is better served by going the 1:1 path
and concentrating on our strengths.

The next challenges are going to be massive.
We need to cope with systems with 256 processors
with non uniform memory ranges.
with non uniform inter process interconnects.
and maybe even with non uniform processors.

Lets get cracking! and I Dan, I hope you feel that you will be
welcome, and appreciated by FreeBSD in general as we head off down the 
track..

Julian