digitalmars.D - Re: std.concurrency and efficient returns
- Sean Kelly <sean invisibleduck.org> Aug 02 2010
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.
Aug 02 2010