Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 27 Mar 2003 10:07:44 -0300
From:      "Daniel C. Sobral" <dcs@tcoip.com.br>
To:        Max Khon <fjoe@iclub.nsu.ru>
Cc:        arch@freebsd.org
Subject:   Re: 1:1 threading.
Message-ID:  <3E82F7A0.2020604@tcoip.com.br>
In-Reply-To: <20030327150313.A8897@iclub.nsu.ru>
References:  <20030327020402.T64602-100000@mail.chesapeake.net> <3E82B795.DDB0C6A4@mindspring.com> <20030327150313.A8897@iclub.nsu.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

-- 
Daniel C. Sobral                   (8-DCS)
Gerencia de Operacoes
Divisao de Comunicacao de Dados
Coordenacao de Seguranca
TCO
Fones: 55-61-313-7654/Cel: 55-61-9618-0904
E-mail: Daniel.Capo@tco.net.br
         Daniel.Sobral@tcoip.com.br
         dcs@tcoip.com.br

Outros:
	dcs@newsguy.com
	dcs@freebsd.org
	capo@notorious.bsdconspiracy.net

A lady stockholder quite hetera
Decided her fortune to bettera:
	On the floor, quite unclad,
	She successively had
Merrill Lynch, Pierce, Fenner, et cetera...



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E82F7A0.2020604>