For the main thread there is usually a platform-specific way to set its size. For Apple platforms this is done via the linker’s
-stack_size argument. See the man page for details.
The situation with secondary threads depends on whether you’re using Dispatch or not:
If you’re using an explicit thread API, that API is likely to include some way to configure the stack size. It seems like you’ve already found this for
If you’re using Dispatch then there’s no way to configure the stack size of the thread that runs your closures.
With regards this last point, you should feel free to file an enhancement request for that feature, although be aware that implementing this would be tricky. Dispatch maintains a pool of worker threads, and there would have to be some way to bind a specific queue to a specific stack size, and thus to a specific subset of worker threads, and once you dive into the details things get really complex.
As to what you can do right now, you have two options:
Option A is not as bad as you might think. You wrote:
We hopefully agree, that in times of grand central dispatch handling
NSThreads "manual" is not the best way to do.
Things are more subtle than that. Dispatch is a good option for many use cases but it’s not the only option. The explicit thread APIs continue to exist because they are various situations where using an explicit thread is better than using Dispatch. This is one of those.
With regards option B, be aware that many standard library types are relatively ‘stack light’ because they store their underlying data in a CoW heap buffer. This includes
Array. You may be able to make good progress adopting this technique in your own data types.
Share and Enjoy
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"