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.
