mingw, gcj, threads

[Adam Megacz <gcj at lists dot megacz dot com>]

Background:

  I'm also posting this to the mingw developer list to get their input.

  Win32 is sort of broken in that thread-local storage is not freed when
  the associated thread dies. TLS is used for jmp_buf's in mingw-sjlj.

  Because of this problem, mingw introduces a bit of a hack: you
  compile with -mthreads, which defines a few symbols, and you also
  link with -mthreads, which includes a global int 'CRT_MT', which is
  set to 1. You also dynamically link against mingwthr.dll, which gets
  notified when threads die, and cleans up their TLS.

Problem:

  I think having to link against (and distribute) a DLL just to clean
  up TLS is undesirable.

  Since gcj is notified of every thread start and stop
  (_Jv_ThreadRegister / _Jv_ThreadUnRegister), it is possible for us
  to take a more elegant approach.

Solution:

  My solution is to include CRT_MT in win32.cc, so that I don't have
  to touch/patch any of the code in gcc/gcc/, and so I don't step on
  the mingw folks' toes. I'll also include (in win32.cc) a fake
  verison of the function that registers a TLS entry for deallocation,
  and deallocate them in _Jv_ThreadUnRegister.

Drawback:

  CNI code linked to gcj code which launches threads and does not
  register them with libgcj will leak approximately 24 bytes of memory
  per thread created.

Advantages:

  We don't have to hack '-mthreads' into the configury. We can create
  statically linked binaries on mingw. We don't have to force
  gcj-compiled apps to distribute Yet Another DLL.

Does this sound okay? If there are no serious objections, I'll submit
a patch.

  - a