Re: Usage of _Jv_AttachCurrentThread, _Jv_AttachCurrentThreadAsDaemon, _Jv_DetachCurrentThread.

On 10/04/2013 10:34, Bryce McKinlay wrote:
> On Tue, Apr 9, 2013 at 7:20 PM, Dave Korn <[email protected]> wrote:
> 
>>   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.
> 
> As Andrew said, these are used by the JNI (& CNI) "invocation API",
> which allows calling into Java code from a non-Java app.
> 
> It might be worth checking if newer versions of the GC already have
> improvements here for Cygwin. libgcj's copy of boehm-gc is very old
> and we really ought to update it!

  Yes indeed!  It turns out that upstream has implemented them since 7.0alpha2
(now at 7.3alpha4).

  Upstream now includes a new support library, libatomic_ops, that is licensed
under a combination of GPLv2 and a custom "MIT-style" licence.  Is that likely
to be any problem?

>>   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?
> 
> Well, I don't think anything in libgcj really uses these. They might
> be useful as part of a debugging interface.

  Good to know, thanks to both of you for the information.

    cheers,
      DaveK