This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
GC_pthread_create() is just a wrapper around pthread_create(), so its arguments and usage are the same as for pthread_create().I think we still have a problem with notifying the GC of a new
thread, if threads are created without going through GC_pthread_create.
I need to find time to work on that.
Do you know of any documentation or examples of using GC_pthread_create? I suppose I'll just look through the source tomorrow.
To return this to gcj, the correct way to use multiple threads with
one JVM is to call JvCreateJavaVM once in the main thread, then create
subsequent threads via GC_pthread_create and call
JvAttachCurrentThread from within those threads?
No, you'd only need to do this in the code which is calling pthread_create().If the Roguewave implementation is in header files, and you can
recompile the files that include it, you might be
able to work around the problem by defining GC_THREADS and including
gc.h before you include those header files. That will redefine
pthread_create to the wrapper that notifies the GC.
I don't believe the implementation is all in the headers, but do I
have to define GC_THREADS in any gcj/c++ program that uses then?
Seems reasonable - just be sure to synchronize the threads correctly if you take this route.My hair-brained scheme for tomorrow is to see if I can launch a proper, GC-registered pthread from the main thread, and then use that thread for all subsequent gcj work, leaving the Rogue Wave threads to do their dirty business in the original thread.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |