handling shared objects

[Alex]

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 :)