-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I thought that I would follow up on my previous message as I have
resolved that problem and wanted to share the solution with the list.

It seems that the problem was that I was creating the VM and going
into my event loop in my main thread.  This seems a legitimate thing
to do to me, but apparently the native threads implementation does not
expect that the main thread will be a Java native thread also.  It
seems that the main thread is the one that sends SIGSTOP to all of the
threads that are Java native threads.  In my case, that meant that my
main thread received a SIGSTOP also and since it is the one
responsible to do SIGCONT, the whole application froze.  This is my
conclusion based on looking at the JDK .diff file and the behavior of
my application alone, so it could be wrong.  I got around this by
spawning another thread to create the VM and run my event loop.  My
main thread then does a sleep() in a loop so that it can still handle
the signals.

Optimally, my main thread would handle my event loop, but right now I
am ticking my entire C/C++ event loop around a synchronized Java
object.  When I have finer grained locking around my C/C++ objects,
I'll put the event loop back where it belongs.

There are caveats, however.  Everything works fine under glibc 2.0 and 
a single processor.  Under glibc 2.1, by calling pthread_create in my
main thread, I force the 2.1 version of some pthread calls into the
system, and that conflicts with the 2.0 versions that libjava.so is
linked against.  I got around this by doing dlopen,dlsym on the
"pthread_create" symbol to force my main thread to get the 2.0
version.  That is gross, but I can take that out when a jdk linked
against 2.1.2 is released.

Under glibc 2.0 and SMP, the native threads version of jdk117_v3 is
unreliable.  Just running the java executable on a pure Java class
sometimes crashes during startup.  I suspect that there are race
conditions in the native threads implementation that are more likely
to be noticed under SMP.  If this is a surprise to anybody, please let 
me know as I have assumed from perusing the mailing list archives that 
there are known SMP vs. native threads problems.

Another problem with the Invocation API is embedding Java GUI apps in
applications that use X/Motif.  I am currently linking against the
latest Lesstif and have made sure that all of my code is compiled with 
- - -D_REENTRANT, but it still does not work reliably.  Sometimes
everything works, sometimes the C/C++ GUI, the Java GUI, or both will
freeze up as if they are no longer receiving events from Xlib.  I
would appreciate any suggestions on this.

Things are looking much better, but they are not perfect yet.  I am
eagerly and optimistically awaiting the 1.1.8 release.

Thanks.

- -- 
Gene McCulley                                          Voice: (407) 265-0772
[EMAIL PROTECTED]                                        Fax: (407) 265-0773
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.10 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE32RwwK+LjkZ54DewRAsMSAJ49tm7/K96pN+BkqCp6Q5nubpTyaACfUqZa
OCFI0Buyv2xdWq7gIS7rj+M=
=6zrF
-----END PGP SIGNATURE-----


----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to