harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject [vmi] thread library
Date Wed, 24 Jan 2007 16:55:44 GMT
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