std.concurrency and efficient returns

[Sean Kelly]

Jonathan M Davis Wrote:

> Okay. From what I can tell, it seems to be a recurring pattern with threads that 
> it's useful to spawn a thread, have it do some work, and then have it return the 
> result and terminate. The appropriate way to do that seems to spawn the thread 
> with the data that needs to be passed and then using send to send what would 
> normally be the return value before the function (and therefore the spawned 
> thread) terminates. I see 2 problems with this, both stemming from immutability.
> 
> 1. _All_ of the arguments passed to spawn must be immutable.

They must be shared.  Immutable data is just implicitly shared.

> 2. _All_ of the arguments returned via send must be immutable.

Same here.

> In the scenario 
> that I'm describing here, the thread is going away after sending the message, so 
> there's no way that it's going to do anything with the data, and having to copy 
> it to make it immutable (as will likely have to be done) can be highly 
> inefficient.

It sounds like what you really want is a thread pool.  Maybe passing a shared delegate would work?  It would be really nice to get unique sorted out though.  Passing unique data via tid.send() should work too.