Re: [go-nuts] Re: help with thread limit

Ignore that as it just triggers a panic if the limit is exceeded, however based on that I'm guessing it's not going to be possible. On Thu, 1 Feb 2024 at 19:01, Steven Hartland wrote: > Sounds sensible to me. > > I haven't read the entire thread, pun intended ;-), so just checking if > you tried

Re: [go-nuts] Re: help with thread limit

Sounds sensible to me. I haven't read the entire thread, pun intended ;-), so just checking if you tried debug.SetMaxThreads ? On Thu, 1 Feb 2024 at 16:42, Steve Roth wrote: > Fair question. In their view, 25 threads per user is a sensible limit

Re: [go-nuts] Re: help with thread limit

Steve, I checked with strace and top -p (press H to see threads). It seems that Go can create few more threads than cores are given by taskset. For example, on an 8 core ARM machine in the cloud, I got these results on a program launching 100 goroutines utilizing a lot of CPU each. $ strace --f

Re: [go-nuts] Re: help with thread limit

In Go, you can not really limit the maximum number of threads that will be created. The runtime itself will create threads whenever needed for things like blocking CGO calls, garbage collection, network polling, etc. As I understand it, GOMAXPROCS only limits the number of threads that would be spa

Re: [go-nuts] Re: help with thread limit

Fair question. In their view, 25 threads per user is a sensible limit. Their mindset is based around single-threaded PHP. And for that reason among others, yes, switching providers is definitely something I will pursue. But that will be a long-term effort. Right now I'm looking for a short-term

Re: [go-nuts] Re: help with thread limit

To be honest I would question if its a usable solution if they are limiting that low on threads, so is the fix to switch or have the provider increase the limit to a sensible number? On Thu, 1 Feb 2024 at 16:08, Steve Roth wrote: > Thanks to the people who suggested how to limit the number of ap

[go-nuts] Re: help with thread limit

Thanks to the people who suggested how to limit the number of apparent cores. Unfortunately, doing that didn't solve the problem. I have the number of cores now limited to two — confirmed by checking runtime.NumCPU() — but the program is still trying to allocate more than 25 threads, and crashing