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. -- Ivan
On 6/9/06, Archie Cobbs <[EMAIL PROTECTED]> wrote:
Ivan Volosyuk wrote: > Yes, I have done this in VMThread.run() method for newly created > threads. But I have seen no way to do this in JNI's ThreadAttach(). > Looks like gnu classpath doesn't require any callbacks (like > thread_attach()) to be called on the attached thread, so the jchevm > doesn't do this. That is why in order to use classlib, this place > needs changes in jchevm and it looks like the same applies to all > other VMs which use gnu classpath interfaces. That is the problem I am > talking about. I haven't looked at the code so these may be questions arising from ignorance.. What native code in classlib requires special thread support and why? Could we simply override those classes and eliminate this need, and just remove (or ignore) the classlib thread stuff? Why can't whatever code uses thread_attach() use the normal JNI methods for thread management instead? JCHEVM should be compatible with any native library that adheres to the JNI spec.. but if it requires other "backdoor" functions to be supplied by the JVM, then in theory we can eliminate that requirement, because after all normal Classpath doesn't require it and it works just fine. Thanks, -Archie
--------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
