------- 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
