[Gc] Solaris and pthread problem
Kenneth C. Schalk
ken at xorian.net
Mon Sep 13 15:58:35 PDT 2004
Hans Boehm wrote:
> Before then, I'm inclined to declare malloc redirection with threads
> broken on Solaris X86. It already is on many other platforms, since
> threads initialization allocates memory, which acquires locks, which
> requires threads to be initialized. The solution is to only lock if
> a second thread has started, and probably to postpone some GC
I've had a similar chicken-and-egg problem with an overridden new
operator on Tru64. It seems that some code in the C++ run-time calls
my new operator at a point early enough that calling GC_init causes a
crash. (It was a while ago that I last looked at this, so I'm a
little fuzzy on the precise details of what went wrong.)
My solution, which I admit leaves a bit to be desired, was to do the
1. Define a static global in the module with the overridden new
operator that indicates whether GC_init has been called.
2. In the overridden new operator, if this variable indicates that
GC_init has been called, call the collector to perform allocations.
Otherwise, use malloc and accumulate all such "early" allocated blocks
into a linked list stored in another static global.
3. Have a static instance of a class which calls GC_init in its
constructor and sets the global to indicate that it has done so.
(This always seems to be called at a point late enough that GC_init
succeeds.) After GC_init returns, it takes the linked list of "early"
malloced blocks and calls GC_add_roots for each one.
I wouldn't hold this hack up as a good solution (and it obviously can
cause some leaks), but it seems to work.
More information about the Gc