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

Sean Kelly sean at invisibleduck.org
Tue Nov 2 07:16:08 PDT 2010


Hm... an alternative to per-thread heaps would be finalizer context info that indicates the owner thread for local data.  It's skewing storage use towards the common case, but would be easier to implement.

On Nov 1, 2010, at 8:58 AM, Steve Schveighoffer wrote:

> 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
> 
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos



More information about the phobos mailing list