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 <[email protected]> >To: Discuss the phobos library for D <[email protected]> >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 <[email protected]> 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<[email protected]> 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<[email protected]> >>>>Newsgroups: digitalmars.D >>>> >>>>On 10/30/2010 09:40 PM, Michel Fortin wrote: >>>> >>>>On 2010-10-30 20:49:38 -0400, Andrei Alexandrescu >>>>><[email protected]> 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 >>[email protected] >>http://lists.puremagic.com/mailman/listinfo/phobos >> _______________________________________________ >phobos mailing list >[email protected] >http://lists.puremagic.com/mailman/listinfo/phobos > >
_______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
