This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
- From: "arno at heho dot snv dot jussieu dot fr" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 23 Oct 2005 23:37:55 -0000
- Subject: [Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
- References: <bug-13212-7355@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #19 from arno at heho dot snv dot jussieu dot fr 2005-10-23 23:37 -------
Subject: Re: JNI/CNI AttachCurrentThread does not register thread with garbage
collector
Hello,
> Arno - you're missing the point. One of the test cases for this is
> rssowl (or more specifically, the SWT Browser widget, which embeds
> Mozilla on Linux). The Mozilla embedding subsystems (as opposed to
> the Mozilla Java plugin system, which is called OJI) don't know
> anything about CNI/JNI, so they can't be expected to create threads
> using the wrapped call to pthread_create.
> In general, AttachCurrentThread must be able to deal with arbitrary threads
> created by third-party native code which doesn't know about CNI or JNI.
OK, ambitious and interesting design goal, which I really hope we
can achieve. However, for me the original PR just stated "it
doesnt work yet" and providing third-party software an interface to
"register" correctly their threads might be a work-around.
However if the "sine qua non condition" is that third-party code
should work as-is, I agree this is not a solution.
> The current implementation cannot cope with arbitrary threads.
Yop, I thought this is what the original PR was about and what I encounter
as well in daily work (which is why I found the PR).
Why not mark it as "this sometimes can be circumvented by teaching
your code how to register threads to the gcj-jvm; officially not supported,
we are working on a clean solution" (or someting like that).
> See the discussion on the fedora Java mailing list.
Thanx! I was unaware of that discussion. I still think it's ambitious
to nothing impose on third party code (at least for the CNI-part (and
BTW I still think that adding more info to gcj/cni.h is
handy and legitimate and does not interfere which third-party code
as long as recompilation is not an issue)).
Kind regards,
Arno
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13212