Re: KSE

On Wed, March 12, 2008 8:26 pm, Julian Elischer wrote:
> 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
>

Well, I for one :-) would like to thank you, David and Daniel for the
tremendous work all that period of time, a lot of people learned from it,
build upon it and so on.

I am very very sure I am not the only one thinking like this, and I agree
with the part that I hope that Daniel remains part of the FreeBSD Project!
It's good to have him aboard!

Cheers,
Remko


-- 
/"\   Best regards,                      | remko_at_FreeBSD.org
\ /   Remko Lodder                       | remko_at_EFnet
 X    http://www.evilcoder.org/          |
/ \   ASCII Ribbon Campaign              | Against HTML Mail and News