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