harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Petrenko" <alexey.a.petre...@gmail.com>
Subject Re: [vmi] thread library
Date Wed, 24 Jan 2007 17:23:31 GMT
Tim,

in fact, after last fixes, hythr library from DRLVM should work with IBM VME...

SY, Alexey

2007/1/24, Tim Ellison <t.p.ellison@gmail.com>:
> 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
>

Mime
View raw message