If we take a closer look at the classlib's hythread, then we may find two different layers within it (I'm hoping that the original hythread authors may correct me):
(1) Lower-level Portability Layer This is mostly contained in the modules\luni\src\main\native\include\windows\hymutex.h and modules\luni\src\main\native\thread\windows\thrdsup.h. It provides a mapping between a "POSIX-like " threading API and the appropriate OS functions This seems like a portability layer for the hythread module which is expressed with the macros, for example: #define MUTEX_ENTER(mutex) EnterCriticalSection(&(mutex)) (2) Upper-level (not classlib specific) This is basically hythread_XXX API. This level incorporates Java threading model specifics, like monitors and interruption support. Plus, support for "JLM" (I guess this is a kind of the debugging API similar to JVMTI?) My understanding is that the classlib is using hythread mostly for the following purposes: - Synchronization (e.g. monitor_enter/exit, wait/notify) - Thread local storage access - Thread creation (needed in hysig module to start signal handling thread) One may also find the real list of the hythread functionality being used in the export def for DRLVM's past "hythread emulator" [1]. Thus it seems layer (1) should be enough for the classlib's purposes, while the layer (2) is mostly needed for JVM itself. Assuming a JVM needs a specific implementation of layer (2), it might make sense in the long term to keep only layer (1) as part of classlib. For now, the existing layer (2) can stay where it is at and not disturbed. It would only be accessed by a JVM that requires it. All other JVMs would simply ignore layer (2). The real problem that can potentially lead to the conflicts between different hythreads is that the classlib currently has the dependencies on VM-specific layer (2). How about replacing the existing hythread_XXX calls in the classlib with the macrodefs from the layer (1)? It would help to resolve the issue of the dependency between the classlib and VM-specific layer (2). Another approach could be to replace hythread_XXX calls with apr_XXX calls in the classlib, which will eventually have the same effect, assuming that the APR is linked statically. This will add a dependency on APR static libraries though, and it probably may make sense to do this if we choose to use APR as a foundation for the portlib. But for now, may be just the macros from the hymutex.h/thrdsup.h would work fine for the classlib? Thanks, Andrey. [1] http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/src/thread/hythr/hythr.def?revision=432130&view=markup On 9/19/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
All, we need to put this issue to bed, as we're tripping over it, it seems. Any thoughts on how to move forward on this? geir --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Andrey Chernyshev 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]
