waiting for approval

[Adam Megacz]

"Boehm, Hans" <hans_boehm@hp.com> writes:
> The second and third also look OK, except that it looks to me like threads
> will be registered twice if the GC is actually in a dll, once using the new
> mechanism, and once using the old?

Yes. That is the case.

> Probably the right thing to do is to check for and ignore duplicates
> whenever a thread is added to the thread table, and to deal with
> duplicate removals correspondingly.

I don't really feel comfortable modifying that code -- I'm pretty
worried that I'd break something.

> If it actually works with dynamic libraries, I'd be happy if you
> just add a FIX ME comment for now.

Unfortunately, I haven't been able to get shared linkage working, so I
can't test this.

Here's my solution: originally, GC_CreateThread only compiled #ifdef
MSWINCE. My original patch changed this to #ifdef WIN32.

Now I've changed it to:

  #if defined(MSWINCE) || (defined(__MINGW32__) && !defined(_DLL))

Hence, if you try to build libgcjgc as a dll, and try to build libgcj
against it, it will fail (link failure since GC_CreateThread won't be
defined). This way people get a compiler error rather than bizarre and
hard-to-debug runtime issues.

This should serve as a warning to anybody who tries to build
libgcj.dll and libgcjgc.dll -- that that configuration has not yet
been tested, and that additional code needs to be added.

Once I've got everything working with static linkage, I'll come back
and work on shared linkage.

Sound good? I'll post a patch in a few minutes.

  - a