Andrei Alexandrescu Wrote: > On 11/4/10 2:06 PM, dsimcha wrote: > > == Quote from Andrei Alexandrescu ([email protected])'s > >> 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. > >> Andrei > > > > Interesting, though I feel like the baseline cruft for Object is getting a > > little > > big. I think we could store the thread ID and the monitor object in the > > same > > memory. If a class is being synchronized on, then it's shared rather than > > being > > owned by a single thread. Therefore, at an offset of 1, a class either has > > a > > pointer to a monitor (if it's shared, and therefore can be destroyed in any > > thread) or a thread ID (if it's unshared). To tell them apart, just see if > > the > > classinfo pointer points to a Monitor or a Thread. > > Yah, my thoughts exactly. My feeling is that this is one of those areas > where it's difficult to find a solution that's at the same time simple > and good. > > Sean, any thoughts?
Right now monitors are structs, typically allocated with malloc. I think they could be transformed to classes in conjunction with some porting of old runtime C code to D, but that's more than a few line fix. It also doesn't address the issue of dynamically allocated structs, but perhaps those will be ruled as not-to-be-finalized-by-the-GC? An alternative would be for the GC to store this info in a lookup table of some sort, though I do like the dual use of the monitor slot in objects.
