> I think you've misunderstood what I meant by optional. I meant that putting > the fiber into the managed context would be optional *at the point where the > fiber was spawned*. > > It sounds like you think: > > 1) The language absolutely needs a "spawn detached" operation, i.e. a way of > starting a new fiber which is queued in the global scheduler, but has no > automatic relationship to its parent. > 2) If the language offered both "spawn managed" and "spawn detached", the > "detached" mode would be overwhelmingly more common (i.e. users and library > authors would want to manage the lifecycle of their coroutines manually), so > the "spawn managed" mode isn't worth implementing. > > Would that be a fair summary of your opinion?
Indeed, yes! That would be a complete summary of my opinion. If the user could choose whether to add fibers to the managed context or not, that would be more acceptable IMO. Then again see point 2, plus even an optional managed fiber context still introduces a certain degree of "magicness" and non-obvious/implicit behavior on initiative of the caller, that can be avoided by simply explicitly returning and awaiting any spawned fibers. Regards, Daniil Gentili.
