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 Wed, 31 Jan 2007 10:04:29 GMT
Ronald Servant wrote:
> On 1/30/07, Tim Ellison <t.p.ellison@gmail.com> wrote:
>> Can you think of a case where the VM and classlib exchange data
>> through TLS like this?
> MACRO_SELF() is the first example that jumps to mind.  It uses TLS
> data to find a per thread data structure that is created by the VM
> when a thread is created and can be referenced by the classlib when
> its natives call into the thread library.

Maybe I'm being dumb, but I don't see it used by the class library code
anywhere?  Can you point me to it.

> In this scenario using two different shared libraries results in the
> per thread data structure being stored in the TLS area that is only
> visible from the VM linked thread library. When the classlib comes to
> look for it, the data is structure is a null pointer.

Understood, and if there are examples of shared data being passed back
and forth between the class library and VM via TLS, then that is a part
of the VMI we haven't properly described.  I'm struggling to find such
an example though.

If there is no such shared data, then having the VM's TLS and classlib's
TLS in these 'separate worlds' is no harm .

>> 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 attached patch is one possible implementation of this idea. It
>> > creates a thread library table (HyThreadLibrary) much like the port
>> > library table. The thread library is created by the port library during
>> > the port library's initialization. The thread library can be obtained
>> > from the port library using the new port_get_thread_library() function.
>> I need to look at the patch to see how you did that, and also allow a VM
>> to provide the impl.
> 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?

>> May as well modify the macros, I don't see a use for the
>> GetThreadLibrary() function directly.
> I will submit an updated patch that removes the VMI modifications and
> updates the macros. Unless someone can see value in the VMI change.

It's good (and brave<g>) of you to be keeping the patch up to date as we
discuss the solution!


View raw message