[bug] One Thread Per Go Routine on OSX 12.4

[davidrenne]

Describe the bug Compiling on Linux 64 bit or Windows, the same program handles 5000 websocket clients connecting to the server just fine. But on OSX 12.4, either golang is blocking the underlying _, message, err := self.client.ReadMessage() which causes the program to SIGABRT

runtime/cgo: pthread_create failed: Resource temporarily unavailable
SIGABRT: abort

I found a go issue which sounded similar but it didnt seem to be fully resolved on there end.

According to @garyburd this should not be creating a separate thread for each go routine reading the responses of the websocket reads.

Can anyone take a look at these two go modules I setup for this issue? Is there anyone brilliant out there know what the heck is going on?

If on mac its easy to recreate:

In one terminal run this:

cd /tmp
git clone https://github.com/davidrenne/gorillaWebsocketsIssue801.git
cd gorillaWebsocketsIssue801/GoCoreWeb
./build_and_run_server.sh

This will compile a listener on port 0.0.0.0:8090/ws with an older gorilla websocket connection (but the issue isnt on the server I can try upgrading GoCore to use 1.5.0). The version of GoCore in these binaries is compiling the old websocket, but all I have to do is cut a release on this commit and you would have to update your go.mod to point to the next version of GoCore if you think the problem is the server on an old gorilla/websocket somehow.

Next run the client on OSX 12.4 who will open up 5000 sockets to your local and will crash as is (note you can comment out the 1500 one in clients.go and it will run but hold about 1500 threads which are under the max threads for OSX):

cd /tmp/gorillaWebsocketsIssue801/GorillaClient
./build_and_run_client.sh

This should throw the runtime/cgo: pthread_create failed: Resource temporarily unavailable unless my machine has something different on it causing this.

Feel free to cross compile the same two programs to other architectures like linux and windows and it does work and works well without any real cpu or memory issues.

…

Versions go version go1.17.12 darwin/amd64

…

Expected behavior

Similar to linux/windows. Not using a thread per go routine reader.

[davidrenne]

If anyone doesn't want to install the 25 packages in the server side I can trim it down to a lot less by only importing GorCore/core/app as a separate module and not importing the entire package and all the sub modules which I did and is why it's a large go mod on the server side. All the indirects can probable be deleted and it will compile. Those are just for other packages we use in GoCore.

[garyburd]

Show the complete stacktrace for the panic.