3 ms·
What fix/patch could the Go team do here to mitigate the issue from happening? It does seem like it would be nice if you could specifically to the runtime the a
by jadbox 8y ago
What fix/patch could the Go team do here to mitigate the issue from happening? It does seem like it would be nice if you could specifically to the runtime the amount of pre-alloc stack size needed. Would this help?
- gen220 8y agoI think this is a trade-off, between configurability/expressiveness and simplicity. Historically, the Go team has favored simplicity. My impression is that the Go team would believe that exposing such a runtime config isn't a good idea. Personally, I agree with you it'd be nice to pre-alloc. But I also think that exposing such an option would probably create more bugs than it would solve. I believe they'd prefer to improve the runtime's internal stack allocation algorithm, while keeping it opaque to the average developer. The proposal mentioned elsewhere in this thread, to re-use allocated routines "under the covers" is an example in that direction. Until they implement something like that (essentially, routine-pooling) in the runtime, these apps will just have to use routine pooling at the application level – which I suppose isn't that bad, after all?