Ruling out arbitrary cost copy construction?

[Steven Schveighoffer]

On Thu, 04 Nov 2010 15:55:07 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 11/4/10 2:45 PM, Steven Schveighoffer wrote:
>> On Thu, 04 Nov 2010 14:38:59 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>> 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?
>
> Probably a thread that dies (by crashing) will never call its  
> destructors.

It is quite possible that a thread exits while there are active, non-GC'd  
objects owned by it in the heap.  There's no way to determine this when  
the thread exits without running a GC collection, which is unacceptable.

simple example of a thread function that exits properly but leaves data in  
the heap:

void mythread()
{
   auto c = new ClassObject();
}

>
>> 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).
>
> If you use File, you use reference counting. We do need to define a  
> policy for copying expensive objects.

hehe, most of my heavy d work has been developing dcollections or from my  
previous job (where I used Tango).  So I haven't yet been using File :)

For the times I have used File, the reference counting aspect of it has  
not been important (i.e. short utilities that exit quickly).

>> You also need to provide a pointer in the object for a linked list for
>> the work-list.
>
> I think it's enough if the thread has the list, but I may as well be  
> wrong.

No, I mean if you have a spot for a pointer in every object, then the  
object memory itself can act as the linked list element that is in the  
worklist.  Otherwise, you have to allocate extra memory to be put into the  
list and which points at the objects to be destroyed (which I think would  
be overkill).  The Thread object would still contain the list head pointer.

>> 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.
>
> These are all interesting options. At the end of the day, what we want  
> to guarantee is no races in non-shared objects.

Understood.  I think we should explore all options, to see what makes the  
most sense.  I did like the description of the way Cocoa does it from  
Michel Fortin on the mailing list.  It might also be worth looking into.

I just was saying that I prefer solutions where we don't bend the entire  
language to cater to reference counting, if we can help it.  I'd rather  
bend the reference counting implementation to fit the language.  Something  
in the middle might be good too.

-Steve