[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
arno at heho dot snv dot jussieu dot fr
Sun Oct 23 23:37:00 GMT 2005
------- 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
> 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)).
More information about the Java-prs