Ruling out arbitrary cost copy construction?

Steven Schveighoffer schveiguy at yahoo.com
Thu Nov 4 12:45:12 PDT 2010


On Thu, 04 Nov 2010 14:38:59 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Thanks to all for a very illuminating discussion. The dialog revealed  
> that the topic of cheap copy construction is oddly linked with the topic  
> of garbage collection: garbage collection calls destructors concurrently  
> with other code, which means reference count code must be interlocked,  
> which makes it not-so-cheap.
>
> This is only a manifestation of a deeper problem: destructors can  
> execute arbitrary code, and, if ran in an arbitrary thread, can cause  
> all sorts of deadlocks and essentially render "shared" inoperant.
>
> Walter and I discussed two possibilities this morning:
>
> 1. Never call class destructors (or never call them if more than one  
> thread is running)
>
> 2. Each destructor should be called in the thread that created the  
> object.
>
> The second solution is quite attractive. It can be implemented by  
> associating each thread with a worklist - a list of objects to destroy.  
> The GC can run in any thread but it will not call destructors. Instead,  
> it adds objects to be destroyed to the threads that created them (this  
> means we need to add a field to each object with the thread ID of the  
> creating thread). When client code calls new, the allocation routine  
> will first inspect the worklist and call the destructors if needed.
>
> I think this can be made to work and has good properties, although a  
> fair amount of details need to be figured out. Please share any thoughts  
> you may have.

What if a thread no longer exists?  Would there be a way to mark such  
dtors that need this feature?  I don't know, because it seems to me like a  
lot of band-aiding for something that is infrequently used (I've gotten  
along fine in D without reference counting for as long as I've used it).

You also need to provide a pointer in the object for a linked list for the  
work-list.

I'm thinking I would prefer to have the destructor and finalizer split, so  
the 'destructor' can tell whether it's being called synchronously or from  
the GC.  Then the dtor itself can handle the whole worklist implementation.

I guess the only extra thing you would need in addition to that is a hook  
so memory allocation from a given thread can be hooked to process the  
worklist.  Or maybe the worklist becomes a standard feature of the thread  
class, and you manually add the task from the destructor instead of the GC  
doing it for you.

-Steve


More information about the Digitalmars-d mailing list