An exegesis of Walter's reference counted slice
deadalnix via Digitalmars-d
digitalmars-d at puremagic.com
Tue Feb 24 14:45:02 PST 2015
On Tuesday, 24 February 2015 at 19:40:35 UTC, Andrei Alexandrescu
wrote:
> I modified Walter's sample code to this:
> http://dpaste.dzfl.pl/f3d854feede9. It uses malloc for both the
> array and the reference count, and also uses @trusted
> minimally. I inserted assert()s here and there to clarify the
> workings. Nothing big except for the careful use of @trusted.
>
Using malloc make the GC blind. It means you can't stored
anything GCed in this. Which means you either need to enforce
this at the interface level (I have no idea how) or remove all
these @trusted in the code.
Generally using malloc is not the right way forward. I do think
that, even for RCed resource, we want them backed by the GC. It
will allow for cycle collection. The main problem with the GC is
not allocation, it is collection, and collection won't fire if
one do not leak.
> 2. Michel's point
> (https://issues.dlang.org/show_bug.cgi?id=14221) reveals the
> largest issue with RC/GC integration. We need to find a fix for
> it if we want to have the GC lift cycles.
>
There is a set of feature that create implicit sharing. GC is
only one of them. They either need to be fixed (and here, you'll
get my point about simple fix aggregating to something more
complex) or make this thread safe.
> So: does DIP25 allow safe slices? Looks that way, though a
> proof would be nice. Does it allow other safe interesting
> structs that own data? Very likely.
As long as you don't plan to own an arbitrary sub graph.
> Does it allow really sophisticated ownership schemes? We need
> to explore that.
Limited, unless you wrap all indirection in some sort of struct
down the road.
> Does it protect against bugs in implementations of safe
> ownership schemes that explicitly release memory? Not too well.
> I think the prevalent idiom will be to accompany such artifacts
> with unittests that make sure unsafe uses (such as fun() above)
> do not compile.
>
I though we wanted to do better than C++...
More information about the Digitalmars-d
mailing list