Escaping the Tyranny of the GC: std.rcstring, first blood

[Jakob Ovrum via Digitalmars-d]

On Monday, 15 September 2014 at 12:47:08 UTC, Robert burner 
Schadek wrote:
> On Monday, 15 September 2014 at 12:11:14 UTC, Jakob Ovrum wrote:
>>>> There's no use of `shared`, so all data involved is TLS.
>>>
>>> Then it must be made sure that send and receive work properly.
>>
>> They do. They only accept shared or immutable arguments (or
>> arguments with no mutable indirection).
>
> compiler says no: concurrency.d(554): Error: static assert  
> "Aliases to mutable thread-local data not allowed."
>
> I used the std.concurrency example

Yes, that was my point. std.concurrency handles it correctly - 
there's no unsafe memory sharing going on with RCString's 
implementation.

If you are suggesting we somehow make this work so it can be a 
drop-in replacement for `string`:

I don't think that should be implicitly supported.

One method would be to support shared(RCString). This isn't very 
practical for this use-case, as since atomic reference counting 
is super slow, you wouldn't want to be using shared(RCString) 
throughout your program. So you'd have to make a copy on each 
side (unshared -> shared, then send, then shared -> unshared) 
which is one copy more than necessary and would still require 
support for shared(RCString) which is non-trivial.

Another option would be to hardcode support for RCString in 
std.concurrency. This would make the copy hidden, which would go 
against good practices concerning arrays in D, and not very 
useful for @nogc if the copy has to be a GC copy. Additionally, 
RCString's interface would need to be compromised to allow 
constructing from an existing buffer somehow.

Maybe the right solution involves integration with 
std.typecons.Unique. Passing an instance of Unique!T to another 
thread is something std.concurrency should support, and RCString 
could be given a method that returns Unique!RCString if the 
reference count is 1 and errors otherwise. Unique's current 
implementation would have to be overhauled to carry its payload 
in-situ instead of on the GC heap like it currently does, but 
that's something we should do regardless.