Tristam MacDonald wrote:

> Would explicitly running a full collect cycle at the end of main (and wrapping logic in an inner function work around this? More likely some would still be left though.

I think it would work if you ensure that no valid references is left in scope when you does so. (set all globals and the local references in main to null)

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.

> The point I don't understand, is why is this only the case when I am using threads? And I think the thread implementation may be a little buggy here anyway, why on earth would the assert statement below cause a 'Bus Error'?

I have no idea.  On Tango, your program outputs:

    starting
    In Thread

Here's the converted code:


    import tango.core.Thread;
    import tango.stdc.stdio;

    class Main
    {
    	this() {
    		printf("starting\n");

    		Thread worker = new Thread(&workerMain);
    		worker.start();
    	}
    	~this() {
    		printf("ending\n");
    	}

    	void workerMain()
    	{
    		printf("In Thread\n");
    	}

    	Thread worker;
    }

    int main()
    {
    	Main m = new Main();

    	return 0;
    }

Sean

Tristam MacDonald wrote:
> Would explicitly running a full collect cycle at the end of main (and wrapping logic in an inner function work around this? More likely some would still be left though.

You can call fullCollectNoStack() to collect everything whether there is a valid reference to it or not.


Sean

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.

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.

They can do both, but if it's important that those resources are explicitly released then you should take steps to manage the object's lifetime.  I could still be convinced that all lingering objects should be collected on shutdown, but I haven't come up with an approach I'm entirely happy with (the most obvious being to simply collect everything and if an exception is thrown then give up, but continue the rest of the shutdown process).

> 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.

Yup.  It doesn't help that there is no way to implement smart pointers in D, given the lack of copy semantics in structs.

> 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. 

FWIW, Tango has a means of hooking the collection routine, which may be used as a means of detecting resource 'leaks'.


Sean

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.