mingw, gcj, threads

Wed Mar 6 16:53:00 GMT 2002

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