harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [vmi] thread library
Date Wed, 24 Jan 2007 17:33:24 GMT
thanks - this was on my list of issues to flog for the day!


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.
> 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.
> Thoughts?
> Tim

View raw message