Ronald Servant wrote: > On 1/31/07, Tim Ellison <[EMAIL PROTECTED]> wrote: >> If there is no such shared data, then having the VM's TLS and classlib's >> TLS in these 'separate worlds' is no harm . > > Upon closer inspection of the implementation the TLS I was referring > to (via MACRO_SELF) is NOT the same TLS as that provided by > hythread_get_tls(), etc... > > So as Angela points out, as long as there is no classlib code using > this hythread_xx_tls() functions directly than it doesn't matter that > there is only a single copy from a single shared library.
Right, that's what I was trying to point out too. So we agree that life is good here. >> >> Or we could provide a working reference impl of the functions for VMs >> >> that don't care, and support testing the portlib without a VM present. >> > >> > I don't have a problem with this, other than having someone >> > accidentally leave the shared library in a distribution that contains >> > a VM with a library of the same name. We would either load the wrong >> > library or again have two libraries loaded (one by the VM and the >> > other by the classlib). >> >> Isn't that just as likely as having the stub version left in by mistake? >> though I hope the stubs would fail earlier and be more obvious :-) > > The stub version fails on startup, and we could likely add an error > message saying it is the stub version. But again, I don't mind either > way. I don't feel too strongly either, but since we have a version of the threadlib today that will allow portlib to be tested independently of any VM, I see no great harm in keeping it around for now. >> > In portlib/build.xml I removed the copy command that copies hythr.dll >> > over to the deploy tree. >> >> Ah, the same way that we are doing the VMI library today. In fact, why >> not just make those thread functions part of the same VMI DLL, then >> there is only one stub replacement required? > > Hmmm... seems like a good idea, but we need to have the portlib link > against a shared library named hythr, so that at runtime it can in > fact find the real one provided by VM, or I am missing something > obvious? or perhaps we get rid of the name hythr and put those > functions in vmi as well? doesn't seem as clean to me. I meant drop the hythr.dll and just export those functions from the vmi.dll Regards, Tim
