dsimcha Wrote: > I was thinking about ways to improve std.concurrency w/o compromising its > safety or the simplicity of what already works. Isn't it unnecessarily > restrictive that a spawned function must return void? Since the spawned > thread dies when the spawned function returns, the return value could safely > be moved to the owner thread. Therefore, the return values wouldn't even have > to be immutable/shared/lacking indirection. The return value could, for > example, be stored in Tid, with attempts to retrieve it blocking until the > spawned thread returns.
That each spawn() results in the creation of a thread whose lifetime ends when the function returns is an implementation details. It could as easily be a thread pool that resets its TLS data when picking up a new operation, user-space thread, etc. In short, I don't think that the behavior of a thread exiting should be a motivating factor for design changes. Does this gain anything over sending a message on exit?
