Re: [vmi] thread library

[Tim Ellison <t....@gmail.com>]

Ronald Servant wrote:
> On 1/31/07, Tim Ellison <t....@gmail.com> 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