RFC: reference counted Throwable

[Walter Bright via Digitalmars-d]

On 9/20/2014 11:26 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang at gmail.com>" wrote:
> On Saturday, 20 September 2014 at 18:18:05 UTC, Walter Bright wrote:
>>
>> Please show me the inc/dec optimized x86 code.
>
> There's no optimization of the inc/dec, you use regular inc/dec within a larger
> xbegin/xend block.
>
> You amortize the cost over all the lock-prefixed instructions you would
> otherwise have executed in that block. There is no locking, there is a
> transaction instead. Only if the transaction fails do you execute the locking
> fallback code.

I strongly suggest taking a look at C++ shared_ptr<T>, compile a simple example, 
and examine the generated code. It is NOT AT ALL as simple as emitting an 
inc/dec pair. I.e. what happens if an exception is thrown between the inc and 
the dec?

If RC was as costless and simple as you are suggesting, everyone would be doing 
it and would have for decades.


>> Suppose I pass a pointer to:
>>
>>    void foo(T* p);
>>
>> How do I do dataflow?
>
> You mean a separate compilation unit that the compiler don't have access to? You
> don't, obviously.

Right. "dataflow" is not the answer.


>> The question was about mixing RC'd and non-RC'd objects.
>
> Well, if you are talking about negative offset for ref counts, then people do
> it. E.g. there are examples of systems that provide C-compatible strings with
> length at offset -4 and ref count at -8.

Now embed that object as a field in some other object.


> If you need to distinguish you can either use address-space info or keep a
> negative int in the non-RC'd object.

Now add that runtime distinguishing logic to the inc/dec code.