[phobos] Fwd: Re: Ruling out arbitrary cost copy construction?

[Steve Schveighoffer]

Ref counting still has to be thread aware because anything allocated on the heap 
can be destroyed in any thread, even if the type is not shared.  I think that is 
Michel's point.  Even if you don't store the reference types on the heap, 
something that contains the reference could be stored on the heap (think of a 
File member of a class).

-Steve


>
>From: David Simcha <dsimcha at gmail.com>
>To: Discuss the phobos library for D <phobos at puremagic.com>
>Sent: Mon, November 1, 2010 11:33:19 AM
>Subject: Re: [phobos] Fwd: Re: Ruling out arbitrary cost copy construction?
>
>Sounds reasonable iff we assume that ref counted stuff will never be shared 
>across threads, which we seem to be assuming anyhow.
>
>
>On Mon, Nov 1, 2010 at 12:21 AM, Andrei Alexandrescu <andrei at erdani.com> wrote:
>
>Alright, then how do we solve refcounting of constant objects (see Michel 
>Fortin's question)? My solution involves casting away const and keeping 
>immutability information at runtime. Is that acceptable?
>>
>>Andrei
>>
>>
>>On 10/31/10 5:32 PM, Shin Fujishiro wrote:
>>
>>I think cheap copy construction is must.  Since any accesses to sealed
>>>range elements involve copy construction.
>>>
>>>I read older discussions and found that they mostly focused on swap
>>>and moveX.  But the problem lies not only in the swap operation.  It's
>>>everywhere and move doesn't help.
>>>
>>>Note that *every* access to an element of sealed range involves a copy
>>>construction.  When sorting a sealed range of BigInts (Array!BigInt),
>>>even an innocent comparison creates two BigInt copies:
>>>
>>>    if (!less(r[i], r[p]))  // Creates two temporary copies.
>>>
>>>I think these copies can't be elided since original objects exist in a
>>>container at the same time.  Still the compared elements could be moved
>>>out and then assigned back, but that's terribly awkward.
>>>
>>>We mostly don't want to move out elements - just want to read them.
>>>Sealed ranges are inherently copy intensive, so if you will put forward
>>>the concept, copy cost of elements must be assumed to be cheap IMO.
>>>
>>>
>>>Shin
>>>
>>>Andrei Alexandrescu<andrei at erdani.com>  wrote:
>>>
>>>I am highly interested in the opinion of Phobos contributors in the
>>>>matter of copy construction (just posted the message below).
>>>>
>>>>Andrei
>>>>
>>>>-------- Original Message --------
>>>>Subject: Re: Ruling out arbitrary cost copy construction?
>>>>Date: Sat, 30 Oct 2010 22:56:24 -0500
>>>>From: Andrei Alexandrescu<SeeWebsiteForEmail at erdani.org>
>>>>Newsgroups: digitalmars.D
>>>>
>>>>On 10/30/2010 09:40 PM, Michel Fortin wrote:
>>>>
>>>>On 2010-10-30 20:49:38 -0400, Andrei Alexandrescu
>>>>><SeeWebsiteForEmail at erdani.org>  said:
>>>>>
>>>>>
>>>>>On 10/30/10 2:24 CDT, Don wrote:
>>>>>>
>>>>>>At the moment, I think it's impossible.
>>>>>>>Has anyone succesfully implemented refcounting in D? As long as bug 3516
>>>>>>>(Destructor not called on temporaries) remains open, it doesn't seem to
>>>>>>>be possible.
>>>>>>>Is that the only blocker, or are there others?
>>>>>>>
>>>>>I managed to define and use RefCounted in Phobos. File also uses
>>>>>hand-made reference counting. I think RefCounted is a pretty good
>>>>>abstraction (unless it hits the bug you mentioned.)
>>>>>
>>>>I like the idea of RefCounted as a way to automatically make things
>>>>reference counted.
>>>>
>>>Unfortunately it's only a semi-automated mechanism.
>>>
>>>
>>>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.
>>
>>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'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++.
>>
>>So, everybody - this is really the time to speak up or forever be silent.
>>
>>
>>Andrei
>>
_______________________________________________
>>phobos mailing list
>>phobos at puremagic.com
>>http://lists.puremagic.com/mailman/listinfo/phobos
>>
_______________________________________________
>phobos mailing list
>phobos at puremagic.com
>http://lists.puremagic.com/mailman/listinfo/phobos
>
>


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20101101/5a081557/attachment-0001.html>