I am also using D for real time applications (audio library, not embedded systems).
Since I'm ensuring allocation don't occur in a real-time loop, I'm quite happy with the way the GC work. We have custom allocators, do we ? I mean, anything which is too slow could use pools anyway. Frank Benoit Wrote: > I am using D for a real time test system. There i have to make sure that > real time code does never use direct or indirect allocations. > I can use the GC in the non real time thread and at start up. I can > preallocate as much as I want. Just, it is not allowed in IRQ handler, > certainly. > > What i did is, i patched the GC to have a callback in the allocation > function. My application can register for that callback and checks the > current thread. If it is a real time thread, an error is generated. > > The disadvantage is, it is a runtime check. The advantage is, i can mix > code that can use the GC and code that can't.