Re: ATTN Windows Users: RFC - GCJ/MinGW and Thread-Safe Exception Handling

[Adam Megacz <megacz at cs dot berkeley dot edu>]

I think I'm guilty of putting this into win32.cc in the first place.

At the time I know that it was the only alternative to depending on a
DLL.  I don't remember the precise details, but at the time, the only
way to be notified of a thread termination on Win32 was to load a DLL
(DLL's are notified of thread creations/deaths in their process) --
the Win32 API simply didn't have any other way for a process to
register to be notified of that sort of thing.

Has this changed?

In the libgcj world, since we spawn all threads, we can put the
deallocation code at the end of the thread-spawning function.  I think
that's the future fix I was thinking of when I wrote "for now...".

I have to admit that I'm pretty far out of date with this stuff, but I
definately remember it causing a lot of pain and heisenbugs in
multithreaded programs with exceptions -- something crazy about
throwing an exception out of one thread and it getting caught in
another thread -- be careful!  Read the sjlj code in gcc first.

Might want to double check this with the mingw folks.

  - a



Danny Smith <dannysmith@clear.net.nz> writes:
> (1) Put this into a object file of its own and add it to link spec as a
> 'startup' object so it 
> overrides the static libmingw.a library version. 
>
> int _CRT_MT = 1;
>
>
> (2) Remove this completely and link against the equivalent one in
> mthr_stub.o (libmingw.a)
>
> extern "C" int
> __mingwthr_key_dtor (DWORD, void (*) (void *))
> {
>   // FIXME: for now we do nothing; this causes a memory leak of
>   //        approximately 24 bytes per thread created.
>   return 0;
> }
>
>
> I don't know why I'm suggesting this. I have never liked the foolery in
> win32.cc and wopuld be glad to see it removed.
>
> Danny
>
>

-- 
PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380