1:1 threading.

[Scott Long]

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