Threading bugs

Myron Alexander someone at somewhere.com
Fri Jun 29 02:18:31 PDT 2007


Tristam MacDonald wrote:
> I guess coming from a C++ background (i.e. no GC), I am having trouble with the whole idea of destructors-as-finalizers, meaning only used to free memory, rather than to manage resources.
> 
> To me this seems a big hole in the language. I know 'scope' is supposed to be used for RAII, but it practice it falls short, due to the inability to return or copy scoped classes in a useful manner. This leads to lots of C-style explicit reference counting (obj.retain(), obj.release(), etc.), without even the C++ convinience of wrapping it in 'fake' pointers.
> 
> AFAIK, no GC'd language has come up with a good solution, and there obviously isn't a simple offhand fix. Maybe constructors/destructors/copying of structs would fill this hole by allowing high-level value types, which would solve RAII by dint of residing on the stack. 
> 
> Sean Kelly Wrote:
>> Tristam MacDonald wrote:
>>> Hmm, I don't see anything relevant in either the changelog or the news group (haven't finished searching the latter though).
>>>
>>> I am not sure I understand, shouldn't all remaining objects have their destructors called when the program exits? What would happen if the object had a non trivial destructor (dispose of shared memory, flush an iostream, etc.)?
>> Running the dtors of all objects on exit is problematic.  Should they 
>> run before or after the module dtors?  What if they are run after the 
>> module dtors but the object in question relied on the module's dtor not 
>> yet having been run?  In Tango, uncollected objects not specifically 
>> cleaned up in a module dtor are not guaranteed to be collected for this 
>> reason.  An alternative would be to run a collection after main() exits 
>> as a part of the cleanup process.  This would get your Main object 
>> below, but it would slow the shutdown process for the sake of collecting 
>> only a very few objects, and I'm not sure it's worthwhile to do so.

I'm not quite sure how D is different from C++ in this instance.

C++ on heap:
main... {
   SomeObject so = new SomeObject ();
   ...
}

End of main, program exits and the destructor of SomeObject is not 
executed. You have to 'delete so;'.

C++ on stack:
main... {
   SomeObject so();
   ...
}

End of main, stack unwound, so::~SomeObject() is executed. If 'so' were 
in a function, and you wanted to return 'so', then you need a copy 
constructor; 'so' is destructed at end of function.

D on heap:
main... {
   SomeObject so = new SomeObject ();
   ...
}

D on stack:
main... {
   scope SomeObject so = new SomeObject ();
   ...
}

I have not tried it yet, but you can write a class copy constructor for 
D and, afaik,  constructors are coming to structs.

I have no idea how to solve the raised gc issues.


Regards,

Myron.


More information about the Digitalmars-d-learn mailing list