Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: neutral (herse.apache.org: 216.86.168.178 is neither permitted
 nor denied by domain of geir@pobox.com)
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <45B78F90.6070605@gmail.com>
References: <45B78F90.6070605@gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <B98DD8F0-FA65-4293-92F9-81E21F6CBBA8@pobox.com>
Content-Transfer-Encoding: 7bit
From: "Geir Magnusson Jr." <geir@pobox.com>
Subject: Re: [vmi] thread library
Date: Wed, 24 Jan 2007 12:36:54 -0500
To: dev@harmony.apache.org


On Jan 24, 2007, at 11:55 AM, Tim Ellison wrote:

> Another attempt to resolve the threadlib mismatch problem between
> classlib and VM <g>  Apologies to those who have been round this loop
> multiple times already.
>
> The original intent of the hythr.dll was to provide a thread library
> that was shared between the VM and class library code.  But as we  
> know,
> all too painfully, we haven't seen that work too well; mainly I would
> say because each VM has a close interest in the thread functionality.
>
> The class library needs to use the threading functions, but the  
> contract
> between classlib and threading is a bit simpler than that between  
> the VM
> and threading.
>
> So the proposal on the table is to discover the APIs that the classlib
> needs, and add them to a new function table in the VMI struct.  That
> would then put the onus on the VM to implement the thread functions.
>
> We may choose to keep the existing threadlib code around as a  
> reference
> for VMs that want to use it, and possibly so that the new class  
> library
> native tests have something to use, but 'in production' the classlibs
> would be expected to use the same thread library code as the VM.

I'd be worried about the implications on testing.  It would be nice  
if users could easily use their implementation as part of the native  
tests.

>
> This means that the VMI would have:
>   - GetPortLibrary(...) = gets portlib function table
>   - GetVMLSFunctions(...) = gets VM local storage functions
>   - GetThreadLibrary(...) = get thread library function table  *new*
>   - all the other dross...
>
> I'm aware that extending the VMI makes it that much more difficult for
> new VMs to play with the Harmony class library code, but in this  
> case it
> seems that trying to provide the threadlib is not solving the right  
> problem.

Why do you say it's that much more difficult?  Don't they have to  
implement this anyway?

geir