harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Salikh Zakirov <Salikh.Zaki...@Intel.com>
Subject Re: [vmi] thread library
Date Wed, 24 Jan 2007 19:18:21 GMT
Tim Ellison wrote:
> 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.

The changes to VMI interface and class library seem to be reasonable and fairly
small. This looks like a good way forward in resolving multiple threading
libraries issue.

However, it will impact launcher significantly. Currently, launcher uses
port library, and port library is dependent on threading library to provide TLS.
If we make threading library VM-specific, then we need somehow resolve launcher
dependency on it. I see two ways:

1) rewrite launcher avoiding using port library, i.e. use OS services directly
etc. It will involve some #ifdefs, but otherwise does not look like too much
new code.

2) rewrite port library not to depend on the threading library statically, e.g.
by including the minimal set of thread-related functions to port library itself.


Mime
View raw message