This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: JvAttachCurrentThread doesn't seem to call GC_new_thread
- From: Andi Vajda <andi at osafoundation dot org>
- To: java at gcc dot gnu dot org
- Date: Thu, 29 Jan 2004 21:07:46 -0800 (PST)
- Subject: RE: JvAttachCurrentThread doesn't seem to call GC_new_thread
- Reply-to: Andi Vajda <andi at osafoundation dot org>
I'm facing a similar problem. I'm using GCJ (3.4 snapshot on OS X, 3.3.2 on
Linux, 3.3.1 mingw on Windows) to compile the Java Lucene package
(http://jakarta.apache.org/lucene) into a shared library and integrate it with
our python based program (via SWIG for the python/c++/cni glue).
The first (main) thread, calls JvAttachCurrentThread(NULL, NULL) the first
time it calls into the GCJ compiled shared library and seems to work fine.
But any subsequent threads calling into GCJ compiled shared library from
python crash in the same place, in GC_local_gcj_malloc, line 353
in pthread_support.c (this is running on Mac OS X 10.3.2).
If I call JvAttachCurrentThread(NULL, NULL) from these threads, it fails in
the same place when java.lang.Thread tries to auto-generate a name for the
thread, while allocating memory for the string.
If I create a bunch of threads ahead of time (while in the main thread) and
call _Jv_AttachCurrentThread(thread) with those whenever they call into the
GCJ compiled lib for the first time from python, it crashes as soon as this
thread tries to allocate any memory while in java.
I noticed that if I add:
GC_init_thread_local(GC_new_thread(pthread_self()));
right after calling _Jv_AttachCurrentThread(thread), the thread runs fine for
a while but the whole process fails soon with 'thread_suspend failed'.
So, to my question:
- what do I need to do with python initiated threads (other than the main,
first thread) so that a GCJ compiled shared library can be called from
them ? This needs to work on Mac OS X 10.3.2 (with gcc 3.4), Linux and
Windows.
Making this possible would allow a seemless integration between python and
java, but this time with python controlling gcj compiled libraries, not the
other way around a-la jython.
Thanks
Andi..