On Tuesday, 4 November 2014 at 14:36:19 UTC, Chris wrote:
On Tuesday, 4 November 2014 at 14:01:16 UTC, anonymous wrote:
On Tuesday, 4 November 2014 at 12:47:11 UTC, Chris wrote:
The following
struct DATA {
short* data;
size_t len;
}
// data and len are provided by a C function
// ...
auto data = mymodule.getSpeechData();
// cast to immutable, because of concurrency
immutable short* tmp = cast(immutable)(data.data);
auto proc = spawn(&processData, thisTid);
send(processData, tmp, data.len);
However, processData never receives "tmp". Is this because
tmp and data.data are still pointing to the same address? If
this is the case, why doesn't the compiler warn me? Or is it
something else (pointer not visible across threads?).
Is there a work around? (I wanted to avoid having to convert
short* to short[] and .idup it.)
Please provide complete test cases. It makes it way easier for
others to help.
One thing I noticed is that receiving immutable(short*) doesn't
work. Instead, it has to be immutable(short)* on the receiving
end. This is because immutable(T*) is automatically converted
to
immutable(T)* on function calls. And apparently receive's
matching mechanism is inconveniently literal.
Ah, thanks a lot, that was it! It has to be immutable(short)*
on the receiving end, now it works.
receive (
(immutable(short)* data, size_t len) {
//...
});
It is indeed inconveniently literal, but I guess there's a
reason for it.
I'm still curious, though, how D handles this internally,
because data.data is still mutable while the other reference to
the same address (tmp) is not. What if I change data.data while
the other thread is being executed?
Just tested it.
writeln(data.data[0]);
data.data[0] = -11;
send(play, tmp, data.len);
writeln(tmp[0]);
//
receive (
(immutable(short)* data, size_t len) {
writeln(data[0];
});
prints
0 // original value
-11 // tmp
-11 // data in the other thread
Is this behavior intended?
