From owner-freebsd-current@FreeBSD.ORG Wed Mar 12 19:26:44 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6EF9D1065674 for ; Wed, 12 Mar 2008 19:26:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outB.internet-mail-service.net (outB.internet-mail-service.net [216.240.47.225]) by mx1.freebsd.org (Postfix) with ESMTP id 419028FC1A for ; Wed, 12 Mar 2008 19:26:43 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Wed, 12 Mar 2008 12:26:42 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 1C3162D60CB; Wed, 12 Mar 2008 12:26:40 -0700 (PDT) Message-ID: <47D82E6F.6010302@elischer.org> Date: Wed, 12 Mar 2008 12:26:39 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: FreeBSD Current , Daniel Eischen Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: KSE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2008 19:26:44 -0000 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