Currently, the KSMachineContext struct in CrashReport has a fixed limit of 100 threads. This limitation may be insufficient for some applications. Since dynamically sizing this array isn't feasible due to its use in UNIX signal handling and mach-Exception, we need to consider whether increasing this limit is necessary.
Necessity: Is the current 100-thread limit adequate for most applications, or are there significant use cases where this limit is exceeded?
Increase Limit: If an increase is necessary, what should the new limit be? Options could include doubling the limit to 200 or selecting another appropriate number.
Would increasing the thread limit be beneficial, and if so, to what extent?
If we can't afford a really big array to guarantee all the threads will be captured, then we should at least guarantee that the crashed thread is in the report.
Currently, the
KSMachineContext
struct in CrashReport has a fixed limit of 100 threads. This limitation may be insufficient for some applications. Since dynamically sizing this array isn't feasible due to its use in UNIX signal handling and mach-Exception, we need to consider whether increasing this limit is necessary.https://github.com/kstenerud/KSCrash/blob/4f00ac9936c4d71d07262c7ad5bb5f6ab3994c8e/Sources/KSCrashRecordingCore/include/KSMachineContext_Apple.h#L44-L53
Would increasing the thread limit be beneficial, and if so, to what extent?