On Monday, 26 November 2018 at 16:27:23 UTC, Steven Schveighoffer
wrote:
On 11/26/18 10:37 AM, Alex wrote:
On Monday, 26 November 2018 at 15:26:43 UTC, Steven
Schveighoffer wrote:
Well, if you want to run calculations in another thread, then
send the result back to the original, you may be better off
sending the state needed for the calculation to the worker
thread, and receiving the result back via the messaging
system.
How to do this, if parts of the state are statically saved in
a type?
For instance, with your toy example, instead of saving the D[]
as a static instance to share with all threads, use idup to
make a complete copy, and then send that array directly to the
new thread via spawn. When the result is done, instead of
sending a bool to say it's complete, send the answer.
Sending an immutable copy is the easiest way to ensure you have
no races. It may be more expensive than you want to make a deep
copy of something, but probably less expensive than the
headache of creating a non-debuggable monster race condition.
Yeah... the problem is:
the D[] array is stored statically not because of threads, but
because every element of it has to have an access to it. So not
to store it statically is the very point I want to avoid.
But the idea is clear now, I think: I should delay the array
expansion until the object is transferred to the other thread.
Then, I expand the whole thing, (statically, as I would like to)
do my calculations there and send back results, as you proposed.
In this way, the object to copy will be a simple copy, because
everything that would need a deep copy will be created in the
proper thread, after the transfer.
Thanks :)
