[Issue 649] New: format() hangs in thread

[Sean Kelly]

Nick wrote:
> After some digging it turns out that the problem is actually in string
> concatination. So a simpler example is to exchange the call
> 
> format(1);
> 
> with
> 
> char[] r;
> r ~= "a";

What's happening is this:

The compiler runtime relies on gc_free to finalize t, which in turn 
waits on the child thread.  At the same time, the child thread attempts 
to allocate memory for the string concatenation and is forced to wait 
for the gc_free call to finish.  This is a classic deadlock situation.

I think the best fix for this would be for the compiler runtime code 
(gc.d: _d_delclass) to explicitly call the object's finalizer and for 
gc_free to simply free memory.  So the GC would only be responsible for 
finalizing objects whose lifetime ends during a collection, not for 
those destroyed as the result of a delete operation.  The consequence of 
this would be that a call to gc_free for an arbitrary block of memory 
will not call the finalizer for that block, even if one is known to 
exist, but this seems a clear separation of responsibilities IMO.  If 
the user really wants the finalizer called he can cast the pointer to 
Object and delete it.

A possible compromise would be for _d_delclass to explicitly finalize 
the object and then set a flag indicating that gc_free should not 
finalize the block, and for gc_free to finalize so long as the 
'finalize' flag is still set.  This may be a bit slower depending on how 
it's implemented, but it would allow gc_free to finalize tagged blocks 
when appropriate.  But again, I think it is probably more appropriate 
for the GC to only finalize on collections, and assume that if gc_free 
is called at other times, then the user does not intend for finalization 
to occur.


Sean