"Steven Schveighoffer" <schvei...@yahoo.com> wrote: > On Tue, 14 Sep 2010 19:09:18 -0400, Sean Kelly > <s...@invisibleduck.org> wrote: > >> Leandro Lucarella Wrote: >> >>> Not quite ready for prime-time yet, but I think it's in a stage when > > > it >>> could be interesting anyway (at least for developers or people that > > > want >>> to experiment): >>> http://llucax.com.ar/blog/blog/post/-1a4bdfba >> >> Nice work! I've gotten this to compile as the GC for druntime using > > D2 > but have ran into a snag. I'm using OSX (ie. no usable debug > > info) but > near as I can tell the issue is: >> >> private T locked(T, alias Code)() >> { >> if (thread_needLock()) >> synchronized (gc.lock) return Code(); >> else >> return Code(); >> } >> >> void* gc_malloc(size_t size, uint attrs = 0) >> { >> if (size == 0) >> return null; >> return locked!(void*, () { >> assert (Invariant()); scope (exit) assert (Invariant()); >> return malloc(size, attrs, null); >> })(); >> } >> >> In the code above, it appears that the anonymous delegate being > > passed > as an alias to locked() is having its stack data > > dynamically allocated > (ie. as a dynamic closure). For normal > > delegate calls this can be > avoided by accepting "scope delegate" > > as the function parameter, but I > haven't found an analog when > > using the alias approach. Obviously, what > happens is that a call > > to gc_malloc() ends up needing GCed memory, so > gc_malloc() is > > recursively called, and on until the stack explodes. > I'll see if > > I can come up with a workaround that continues using the > alias > > template parameter. > > What if you passed it through a scope delegate function? > > i.e. > > void *lockedproxy(scope void* delegate() dg) > { > return locked!(void *, dg); > }
I could simply change it to a function that accepts a scope delegate. It just isn't as efficient as the alias approach. But an indirect call is pretty small potatoes in this case anyway. I tried this and it worked, and the I ran into an issue where the object used for the lock (classinfo for GCLock) was apparently null. I'll look into that today.