On 1/25/07, Tim Ellison <[EMAIL PROTECTED]> wrote: [SNIP]
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).
Making the threadLib functions an extension of the portLib function table seems a little odd to me. IMHO it implies that the components portLib and threadLib are being provide together. When in fact the portLib is Harmony code and the threadLib is a per VM implementation.
Any other options?
We could pass in an initialized threadLibrary into the portLibrary initialization functions -OR- we could, as mentioned above have the portLibrary do the initialization of the thread Library -OR- a mix of both (pass in a null for threadLibrary means please create one). We could then add a function to the portLibrary that would return the threadLibrary function table. In either case, I don't see the thread functions being a part of the same table as the port functions. This would also allow us to provide the vmi get thread library function by using the portLibrary. I am working on a patch to implement this now with the IBM VME, I hope to make it available for review/evaluation early next week. Ronald Servant -- J9 VM Development IBM Ottawa Software Lab
