Explicit memory deallocation

Frank Benoit keinfarbton at googlemail.com
Mon Mar 10 10:37:01 PDT 2008


Jarrett Billingsley schrieb:
> "Neil Vice" <psgdg at swiftdsl.com.au> wrote in message 
> news:fr3k2v$30ss$1 at digitalmars.com...
> 
>> "disable() temporarily disables garbage collection cycle, enable() then 
>> reenables them."
>>
>> Given this I suspect that the GC still expects to be in control of memory 
>> so even though the GC thread may not be running dynamically freeing 
>> things, constructor calls will still register pointers with the GC and 
>> expect some sort of internal consistency you are breaking with explicit 
>> destroys perhaps...
> 
> The current GC implementation that D uses (no matter what library you're 
> using) is synchronous, that is, it does not run in a separate thread.  GC 
> collections will only happen on memory allocations.  When the GC is 
> disabled, it should not perform any collections. 
> 
> 

(tango user)
the GC disable disables collection runs as already said.
That means, if there is no more memory, new memory is requested from the 
OS. In the normal case, the GC would first do the collection to try to 
get the needed memory. Everything else should work like befor.

Explicit calls to "delete" should work as usual.



More information about the Digitalmars-d mailing list