From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6782 invoked by alias); 10 Apr 2013 08:24:41 -0000 Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org Received: (qmail 6765 invoked by uid 89); 10 Apr 2013 08:24:41 -0000 X-Spam-SWARE-Status: No, score=-8.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_IB autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 10 Apr 2013 08:24:40 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r3A8OdRx023015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Apr 2013 04:24:39 -0400 Received: from zebedee.pink (ovpn-113-41.phx2.redhat.com [10.3.113.41]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r3A8ObOi003203; Wed, 10 Apr 2013 04:24:37 -0400 Message-ID: <516521C5.1040308@redhat.com> Date: Wed, 10 Apr 2013 08:24:00 -0000 From: Andrew Haley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Dave Korn CC: GCC Java Subject: Re: Usage of _Jv_AttachCurrentThread, _Jv_AttachCurrentThreadAsDaemon, _Jv_DetachCurrentThread. References: <51645BD5.3090906@gmail.com> In-Reply-To: <51645BD5.3090906@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-04/txt/msg00001.txt.bz2 On 04/09/2013 07:20 PM, Dave Korn wrote: > [ 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. People may choose to call Java from an already-running program. In that case, the thread already exists, and catching it on startup is impossible. > 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? I'll leave that to the GC list. Andrew.