[dmd-concurrency] shared arrays

[Steve Schveighoffer]

----- Original Message ----

> From: Andrei Alexandrescu <andrei at erdani.com>
> 
> Steve Schveighoffer wrote:
> > or these?
> > 
> > b.dup; T t; b ~= t; b ~= a;
> > 
> > But really, I don't understand why it's ok to copy i.e. a
> > shared(char)[] where half of it might have changed, but it's not OK
> > to copy an array of large types.
> 
> The array does not enforce any particular relationship between its members.

A shared(char)[] does have a relationship between it's members -- its a string!

example of code that is destined for invalid output:

void foo(shared(char)[] input, shared(char)[] output)
{
   output[] = input[];
}

main()
{
   shared(char)[] a = cast(shared(char)[])"hello".dup;
   shared(char)[] b = cast(shared(char)[])"world".dup;
   shared(char)[] c = new shared(char)[5];

   auto ta = spawn(&foo, a, b);
   auto tb = spawn(&foo, b, c);
   ta.wait(); // unsure of API for this
   tb.wait();
   writeln(c);
}

I'd expect output to match the regex [hw][eo][lr]l[od]

Note also that shared(char)[] elements can be multi-byte code-points!  You could easily generate an invalid string that way (essentially tearing).

The problem is, the compiler doesn't know with an array of items whether it's the array that must be atomic or the elements that must be atomic, or some other relationship (such as a group of elements are related as in utf-8 code points).  It should either refuse copying any data, or allow copying any data.  Making a decision based on assumptions of the array semantic meaning doesn't seem right to me.

-Steve