From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5009 invoked by alias); 9 Apr 2013 18:17:16 -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 4999 invoked by uid 89); 9 Apr 2013 18:17:16 -0000 X-Spam-SWARE-Status: No, score=-4.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KHOP_RCVD_TRUST,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_IB autolearn=ham version=3.3.1 Received: from mail-we0-f173.google.com (HELO mail-we0-f173.google.com) (74.125.82.173) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 09 Apr 2013 18:17:15 +0000 Received: by mail-we0-f173.google.com with SMTP id t57so5434818wey.4 for ; Tue, 09 Apr 2013 11:17:13 -0700 (PDT) X-Received: by 10.180.90.35 with SMTP id bt3mr21710299wib.4.1365531433491; Tue, 09 Apr 2013 11:17:13 -0700 (PDT) Received: from [192.168.2.99] (cpc27-cmbg15-2-0-cust220.5-4.cable.virginmedia.com. [86.27.188.221]) by mx.google.com with ESMTPS id dp5sm27386066wib.1.2013.04.09.11.17.12 (version=SSLv3 cipher=RC4-SHA bits=128/128); Tue, 09 Apr 2013 11:17:12 -0700 (PDT) Message-ID: <51645BD5.3090906@gmail.com> Date: Tue, 09 Apr 2013 18:17:00 -0000 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: GCC Java Subject: Usage of _Jv_AttachCurrentThread, _Jv_AttachCurrentThreadAsDaemon, _Jv_DetachCurrentThread. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-04/txt/msg00000.txt.bz2 [ 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