public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
From: Dave Korn <dave.korn.cygwin@gmail.com>
To: GCC Java <java@gcc.gnu.org>
Subject: Usage of _Jv_AttachCurrentThread, _Jv_AttachCurrentThreadAsDaemon, _Jv_DetachCurrentThread.
Date: Tue, 09 Apr 2013 18:17:00 -0000	[thread overview]
Message-ID: <51645BD5.3090906@gmail.com> (raw)

[ Please Cc: me in replies, I'm not subbed to java@ list. ]

    Hi Java list,

  Under what conditions would the thread attach/detach functions (from
libjava/java/lang/natThread.cc) listed in the title of this email be called?

  My motivation for asking this is because they call the _Jv_GCAttachThread
and _Jv_GCDetachThread thread functions in libjava/boehm.cc.  These functions
key off the existence of pthread_getattr_np on the host to call the boehm-gc
functions GC_register_my_thread and GC_unregister_my_thread like so:

> void
> _Jv_GCAttachThread ()
> {
>   // The registration interface is only defined on posixy systems and
>   // only actually works if pthread_getattr_np is defined.
>   // FIXME: until gc7 it is simpler to disable this on solaris.
> #if defined(HAVE_PTHREAD_GETATTR_NP) && !defined(GC_SOLARIS_THREADS)
>   GC_register_my_thread ();
> #endif
> }
> 
> void
> _Jv_GCDetachThread ()
> {
> #if defined(HAVE_PTHREAD_GETATTR_NP) && !defined(GC_SOLARIS_THREADS)
>   GC_unregister_my_thread ();
> #endif
> }

  Recent versions of the Cygwin DLL have added pthread_getattr_np, which
triggers the #if'd code to compile, but the win32/Cygwin thread support code
in boehm-gc doesn't implement these functions, so libjava fails to link.

  I could fix this by either adding a !defined(GC_WIN32_THREADS) in the same
way as Solaris disables these functions, or I could add an implementation of
the functions in boehm-gc for Cygwin, which is posixy and pthread-based.

  In order to decide which approach to take, I'd like to understand the
purpose of registering/deregistering an existing thread as opposed to catching
it on startup and exit via the pthread_create/pthread_join/thread_start
wrappers that already exist, hence my question about when and why the
functions in natThread.cc (which are the only users of the boehm.cc functions)
would be invoked.

  Also on the same topic, would there be any value added by providing Cygwin
implementations of GC_suspend_thread, GC_resume_thread and
GC_is_thread_suspended, which are called from _Jv_SuspendThread,
_JV_ResumeThread, _JV_IsThreadSuspended in boehm.cc and currently #if'd out by
a test on GC_WIN32_THREADS?

    cheers,
      DaveK

             reply	other threads:[~2013-04-09 18:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-09 18:17 Dave Korn [this message]
2013-04-10  8:24 ` Andrew Haley
2013-04-10  9:34 ` Bryce McKinlay
2013-04-10 23:18   ` Dave Korn
2013-04-11  5:03     ` Boehm, Hans

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=51645BD5.3090906@gmail.com \
    --to=dave.korn.cygwin@gmail.com \
    --cc=java@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).