- My Thread class uses private objects to implement sleep() and join() in terms of Object.wait(). The VM notify()'s this object when the thread exits. This means all the complexity of sleeping (and handling Thread.interrupt()) can be put in Object.wait() and not duplicated elsewhere.
Could you post your versions? It might be interesting to see whether we can adopt this approach as default in the vm/reference implementation. VMThread now does have a lot of native methods. But I believe I discussed some of these issues with Jeroen and if I remember correctly there were some subtle issues with just doing everything as wrappers over Object.wait()/notify().
I would be very unhappy about this. Sleep in JamVM is done by waiting on an internal monitor, which is what Object.wait() maps down to (the monitor associated with the Object) and joining threads wait on the vmthread associated with the thread, which is notified on exit. So all code is done in terms of "monitor wait", which handles interrupt, so JamVM doesn't duplicate code either. JamVM uses thin locks which map down to a real monitor in the presence of contention. Join/sleep by definition requires a real monitor, so I side step the redundant monitor lookup.
Hmm.. sounds like JamVM does the same thing as I described pretty much. Why then "unhappy" ? I must be missing something.
-Archie
__________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
