RE: libgcj/117: _Jv_PthreadCheckMonitor test is not portable.

["Boehm, Hans" <hboehm at exch dot hpl dot hp dot com>]

It seems to me the problem is likely to be too constrained to use one of the
existing solutions.  I think we need:

1) Maximal interoperability with pthread-based code (and perhaps
win32-threads based code on win32?).  You can't assume that "native" code
uses whatever interface library you chose.  My impression is that eliminates
the Mozilla one?

2) Full support of the functionality required by Java.  I think that
currently eliminates the Gnome one, which doesn't appear to support
recursive mutexes, for example?

3) Ideally negative overhead relative to pthreads.  Or enough hooks to add
some flavor of platform-specific thin locks later.  This stuff seems to be a
lot more performance critical for Java than it is for most other clients,
and is probably more performance critical for gcj than Mozilla.  That may
eliminate them both (again?).

Hans

-----Original Message-----
From: Joerg Brunsmann [mailto:joerg.brunsmann@FernUni-Hagen.de]
Sent: Friday, December 10, 1999 4:55 AM
To: Tom Tromey
Cc: java-discuss@sourceware.cygnus.com
Subject: Re: libgcj/117: _Jv_PthreadCheckMonitor test is not portable.


Tom Tromey wrote:

> I agree something better is needed.  I already have a hard time
> keeping track of all the cases, and I wrote the code.  I don't have an
> opinion on what exactly should be done though.

I can't argue technically but I argue with: why bother if someone
else has already gone through the pain. For alternative OS thread 
layer see GLib and NSPR:

  http://cvs.gnome.org/bonsai/rview.cgi?cvsroot=/cvs/gnome&dir=glib/gthread
&
  http://lxr.mozilla.org/seamonkey/source/nsprpub/

Jörg