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.
