Ruling out arbitrary cost copy construction?

[Michel Fortin]

On 2010-10-30 23:56:24 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> On 10/30/2010 09:40 PM, Michel Fortin wrote:
> 
>> But like File and many similar ref-counted structs, it has this race
>> condition (bug 4624) when stored inside the GC heap. Currently, most of
>> Phobos's ref-counted structs are race-free only when they reside on the
>> stack or if your program has only one thread (because the GC doesn't
>> spawn threads if I'm correct).
>> 
>> It's a little sad that the language doesn't prevent races in destructors
>> (bug 4621).
> 
> I hope we're able to solve these implementation issues that can be seen 
> as independent from the decision at hand.

Whether they're independent or not depends on the assumptions behind 
your question. Since everywhere you propose ruling out arbitrary-cost 
copy construction you also suggest COW with a reference counter, my 
understanding is that you assume COW is usable and efficient.

Now, perhaps this isn't bothering you, but keep in mind that 
std::string in C++ was originally specified in a way that allows COW, 
and this ability was removed in C++0x because it isn't efficient in a 
multithreaded environment. What makes you think it'll work differently 
for D?

Fixing the bugs above will either 1) affect the performance of the 
ref-counted things (need to use atomic ops on the counter) or 2) 
restrict usage of RefCounted and others to non-GC memory for 
multithreaded programs (as the current design does, even though the 
compiler doesn't warn you). This is a drawback you should consider 
before asking everyone to use copy on write with reference counting. I 
haven't seen you acknowledge it yet.


> Walter and I discussed the matter again today and we're on the brink of 
> deciding that cheap copy construction is to be assumed. This simplifies 
> the language and the library a great deal, and makes it perfectly good 
> for 95% of the cases. For a minority of types, code would need to go 
> through extra hoops (e.g. COW, refcounting) to be compliant.

I take note that disabling postblit and forcing the use of a separate 
copy function would also be compliant. :-)


> I'm looking for more feedback from the larger D community. This is a 
> very important decision that marks one of the largest departures from 
> the C++ style. Taking the wrong turn here could alienate many 
> programmers coming from C++.

As far as I understand, nothing would prevent me from writing a value 
type with arbitrary-cost copy construction if I wanted to. And someone 
could have good reasons to do this (porting a C++ app for instance).

I'm not opposed to the idea of ruling out arbitrary-cost postblits, but 
I fear it might be futile. If std::string is any indication, COW 
doesn't scale well with multithreading. There is a way to make COW 
efficient for thread-local objects in the GC-heap, but that would 
require thread-local GC heaps, and this has been ruled out in the 
design of 'shared' and 'immutable'.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/