Michel Fortin wrote:
Le 27-juin-2013 à 16:56, Walter Bright a écrit :
> What I'm trying to accomplish with this proposal is:
>
> 1. A way to do ref-counted memory allocation for specific objects
> 2. Do it in a guaranteed memory safe manner (at least for the user of those
objects)
> 3. Do it in a way that does not interfere with people who want to use the GC
or do manual memory management
> 4. Not impose penalties on non-refcounted code
> 5. Do it in a way that offers a similar performance and overhead profile to
C++'s shared_ptr<T>
> 6. Do it in a way that makes it usable to construct COM objects, and work
with NSObject's
> 7. Not require pointer annotations
> 8. Address the most common "why I can't use D" complaint
>
> What I'm not trying to accomplish is:
>
> 1. Replacing all memory allocation in D with ref counting
That list is great for limiting the scope of your DIP. Make sure you include it
in the DIP.
So if we return to the core of it, here's the problems that still need solving:
1. Depending on the reference counting scheme implemented, it might be more
efficient to have a single operation for an assignment (retain a/release b)
operation. I think that should be allowed.
2. If the pointer variable is shared assignment must be atomic (done under a
lock, and it must always be the same lock for a given pointer, obviously).
3. If the pointer variable is shared, reading its value must be done atomically
with a retain too.
Here's a suggestion for problem number 1 above:
class MyObject
{
// user-implemented
static void opRetain(MyObject var); // must accept null
static void opRelease(MyObject var); // must accept null
// optional (showing default implementation below)
// this can be made faster with for some implementations of
ref-counting
// only call it for an assignment, not for
constructing/destructing the pointer
// (notably for Objective-C)
static void opPtrAssign(ref MyObject var, MyObject newVal) {
opRetain(newVal);
opRelease(var);
var = newVal;
}
}
This maps 1 on 1 to the underlying functions for Objective-C ARC.
I don't have a solution for the shared case. We do in fact have a tail-shared
problem here. If I have a shared(MyObject), the pointer is as much shared along
with the object. When the pointer itself is shared, we need a lock to access it
reliably and that can only be provided by the outer context.
If we had a way to express tail-shared, then we could repeat the above three
functions for tail-shared object pointers and it'd work reliably for that.
