Date: Thu, 27 Mar 2003 08:28:51 -0700 From: Scott Long <scott_long@btc.adaptec.com> To: "Daniel C. Sobral" <dcs@tcoip.com.br> Cc: arch@freebsd.org Subject: Re: 1:1 threading. Message-ID: <3E8318B3.2020801@btc.adaptec.com> In-Reply-To: <3E82F7A0.2020604@tcoip.com.br> References: <20030327020402.T64602-100000@mail.chesapeake.net> <3E82B795.DDB0C6A4@mindspring.com> <20030327150313.A8897@iclub.nsu.ru> <3E82F7A0.2020604@tcoip.com.br>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel C. Sobral wrote: > Max Khon wrote: > >> hi, there! >> >> On Thu, Mar 27, 2003 at 12:34:29AM -0800, Terry Lambert wrote: >> >> >>>>> After reading your 1:1 threading code, I think you needn't >>>>> hack current KSE code to build your own 1:1 threading code. >>>>> Our code allow you to do this, actully, it's my earlier >>>>> idea to let 1:1 be implemented in our M:N code base, but never >>>>> had told this to julian or others. >>>> >>>> >>>> It was actually done outside of KSE on purpose. It keeps the API >>>> simpler >>>> and cleaner. It keeps the implementation cleaner. It keeps it out >>>> of the >>>> majority of the KSE code paths aside from thread_suspend and related >>>> code. >>>> >>>> I wanted something small and stable that built on top of KSE provided >>>> primitives but did not actually use the KSE apis. This makes it easier >>>> for KSE to continue growing and changing while the 1:1 code remains >>>> simple. It also removes some of the cost associated with doing KSE. >>> >>> >>> This isn't really a legitimate argument. >> >> >> >> Seconded. do you have numbers that clearly show that using Julian's >> approach >> leads to serious performance penalty? Using KSE APIs is not that >> difficult >> as far as I understand, so why we need to introduce more hacks? > > > As much as I'd prefer the 1:1 threading to use as much of the KSE code > as possible, Jeff's decision wasn't related to performance issues. > > What Jeff wanted to do is to _avoid_ using as much of the KSE API as > possible so his code wouldn't get in the way of that API, with two > obvious benefits: > > 1) Changes to that API (and there have been some in the past) won't > affect his 1:1 threading code and, thus, won't upset real applications > using that threading. > > 2) His 1:1 threading code won't slow down further KSE development nor > influence any changes to the KSE API. > > The reason I personally prefer otherwise is so that (1) above won't be > true. Ie, any bugs or performance issues introduced in the KSE code > *will* affect real applications, so that they can be detected and fixed. > Once 5-STABLE happens, users of 5.x can no longer be guinea pigs for KSE development. By keeping the 1:1 and M:N API's separate, KSE can progress in 6-CURRENT until it is proven while still allowing MFC's to 5-STABLE to happen without too much pain. Later on down the road when KSE matures, or when we decide that 1:1 should really just be a special case of M:N, we can look at addressing the above concerns and possibly MFC'ing the results back to 5-STABLE. But for now we need to allow for 5-STABLE to actually be usable and maintainable. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E8318B3.2020801>