This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]