public inbox for java-prs@sourceware.org
help / color / mirror / Atom feed
From: "arno at heho dot snv dot jussieu dot fr" <gcc-bugzilla@gcc.gnu.org>
To: java-prs@gcc.gnu.org
Subject: [Bug libgcj/13212] JNI/CNI AttachCurrentThread does not register thread with garbage collector
Date: Sun, 23 Oct 2005 23:37:00 -0000	[thread overview]
Message-ID: <20051023233755.20578.qmail@sourceware.org> (raw)
In-Reply-To: <bug-13212-7355@http.gcc.gnu.org/bugzilla/>



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


  parent reply	other threads:[~2005-10-23 23:37 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-13212-7355@http.gcc.gnu.org/bugzilla/>
2005-10-07 13:49 ` stewart at neuron dot com
2005-10-12 18:11 ` tromey at gcc dot gnu dot org
2005-10-12 20:29 ` stewart at neuron dot com
2005-10-22 20:58 ` arno at heho dot snv dot jussieu dot fr
2005-10-23  0:21 ` arno at heho dot snv dot jussieu dot fr
2005-10-23  0:22 ` arno at heho dot snv dot jussieu dot fr
2005-10-23  0:24 ` arno at heho dot snv dot jussieu dot fr
2005-10-23  0:28 ` arno at heho dot snv dot jussieu dot fr
2005-10-23 10:44 ` greenrd at gcc dot gnu dot org
2005-10-23 23:37 ` arno at heho dot snv dot jussieu dot fr [this message]
2006-01-09 17:25 ` aph at gcc dot gnu dot org
2006-01-09 17:32 ` greenrd at gcc dot gnu dot org
2006-01-09 17:41 ` jakub at gcc dot gnu dot org
2006-01-09 17:43 ` jakub at gcc dot gnu dot org
2006-01-09 18:21 ` cagney at redhat dot com
2006-01-13 22:44 ` tromey at gcc dot gnu dot org
2006-03-24 14:08 ` rguenth at gcc dot gnu dot org
2006-03-24 15:35 ` rguenth at gcc dot gnu dot org
2006-03-24 17:41 ` aph at gcc dot gnu dot org
2006-03-25  1:07 ` matz at suse dot de
2006-03-30  7:00 ` mckinlay at redhat dot com
2006-03-30 15:48 ` rguenth at gcc dot gnu dot org
2006-03-30 15:51 ` mckinlay at redhat dot com
2006-05-22 16:16 ` rguenth at gcc dot gnu dot org
2006-06-10 18:00 ` arno at heho dot snv dot jussieu dot fr
2006-07-14 14:02 ` davidf at sjsoft dot com
2006-08-21 22:07 ` tromey at gcc dot gnu dot org
2006-08-21 22:09 ` tromey at gcc dot gnu dot org
2006-09-01 16:16 ` tromey at gcc dot gnu dot org
     [not found] <20031127132523.13212.alessio@itapac.net>
2005-09-11  2:59 ` david at jpackage dot org
2005-09-11  3:02 ` billy dot biggs at gmail dot com
2005-09-15  0:27 ` greenrd at gcc dot gnu dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051023233755.20578.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=java-prs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).