It even don't require change to classlib, but rather to classlibadapter. The main drawback of this approach: it requires changes to _all_ VMs which works successfully with gnu classpath to work with classlib/classlibadapter. There is no other visible obstacles. -- Ivan
On 6/19/06, Archie Cobbs <[EMAIL PROTECTED]> wrote:
Ivan Volosyuk wrote: > As far as I can see classlib uses port library libprt.so which is > intended to be used by VM as low level layer above OS threading > system. Some kind of abstraction of underlying OS primitives. The port > library is widely used in classlib. The port library data is > accessible via TLS (it is done imho to support multi VM environments). > To initialize each thread's TLS pointer to the port library the > thread_attach() function is needed. We could handle this in the following manner: let's define two well-known static native methods (Thread.internaAttach() and Thread.internalDetach()). Then, if these exist, the VM will invoke them from within each thread at the beginning and ending of its lifetime. This would require a simple change to the classlib code and any classlib VM's. However, it would be a good change, because it would be making explicit a VM-classlib dependency that is now implicit. Thoughts on this approach? -Archie
-- Ivan Intel Middleware Products Division --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
