From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20597 invoked by alias); 23 Oct 2005 23:37:55 -0000 Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org Received: (qmail 20579 invoked by alias); 23 Oct 2005 23:37:55 -0000 Date: Sun, 23 Oct 2005 23:37:00 -0000 Message-ID: <20051023233755.20578.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: java-prs@gcc.gnu.org From: "arno at heho dot snv dot jussieu dot fr" X-SW-Source: 2005-q4/txt/msg00202.txt.bz2 List-Id: ------- 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