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 Re: [vmi] thread library
Date Thu, 25 Jan 2007 23:23:00 GMT
Salikh Zakirov wrote:
> 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.

The same thought came to me soon after posting; there is a dependency on
threadlib from the portlib, and the portlib functions don't get a
reference that can reach 'back' to the VMI struct.

So while it may be apparent in the launcher, it would be equally
apparent in the portlib functions themselves, since they would have no
reachable threadlib.

So maybe, as you say, we need to make the threadlib functions an
extension of the current portlib function table rather than the VMI
struct, and have them provided by a DLL loaded by the VM (and the thread
function table populated in the portlib initialization code).

Any other options?

View raw message