D1 garbage collector + threads + malloc = garbage?

[Sean Kelly]

Walter Bright Wrote:

> Sean Kelly wrote:
> > Leandro Lucarella Wrote:
> > 
> >> Bane, el 11 de diciembre a las 06:00 me escribiste:
> >>> Bug with GC fullCollect() in multithreaded environment. Grauzone
> >>> explained it here
> >>> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=99610
> >>> 
> > 
> > To be perfectly safe, it's a tiny bit trickier than that.  You have
> > to always lock on allocations instead of just locking the collection
> > cycle in single-threaded apps.  I think the reason for this is that
> > once the lock is acquired it must be held until the current thread
> > exits the GC code, and the "synchronized" statement only allows you
> > to lock for the length of the collect() call (because the start and
> > end must be within the same scope).  However, this /may/ actually be
> > a separate bug with the D 1.0 GC.  I really can't recall for sure if
> > this was an issue with collecting when all the other threads were
> > suspended.
> 
> Yes, the lock on the gc must still be held until the collection work is 
> completed, but the other threads can be unfrozen once the mark phase is 
> complete.

Hm... so if a dtor creates a new thread then that thread could enter and "lock" the GC while the first thread is still completing its allocation.  Couldn't this cause problems?