Description
debug.SetMaxThreads has a default limit of 10k threads, which is enforced by runtime.checkmcount when the M is created.
https://go.dev/cl/485500 creates an M for every C thread that calls into Go, freeing the M only when the thread exits. Thus, 10k unique C threads calling into Go at least once will trigger the thread exhaustion throw (assuming the threads don't exit). Prior to CL 485500, the 10k threads would all need to call into Go concurrently to trigger the throw.
I don't think we strictly need to do anything. A program with 10k C threads is exceptional and I think it is reasonable to say that such programs should adjust debug.SetMaxThreads.
On the other hand, the primary purpose of this limit is to prevent Go programs from accidentally fork-bombing the system. e.g., by creating 1 million goroutines which all block on a system call, thus requiring 1 million threads. This concern doesn't really apply to threads created by C, since by definition we aren't automatically creating threads. Thus, I think it would reasonable to exclude extra Ms from the SetMaxThreads limit.