3 ms·
> I think this is due to the go runtime allocating an OS thread for each goro as it goes through the socket close() blocking call. I think it has to do this to
by aaronblohowiak 14y ago
> I think this is due to the go runtime allocating an OS thread for each goro as it goes through the socket close() blocking call. I think it has to do this to maintain concurrency
I highly doubt that it is creating a thread per goro on client disconnect. If you have a minimalish example of this, the golang mailing list would be very interested in working with you to identify what went wrong and create a patch if it is an issue with the Go implementation.
- evmar 14y agoIn case you didn't see it, I commented above with a link to a bug.
- tptacek 14y agoBlocking system calls spawn OS threads in Go, which can be cached and recycled for new goroutines. You don't see this if you code to pkg/net because it multiplexes i/o with a select/kqueue goroutine, but you'll see it right away if you code directly to the syscalls. Close isn't a blocking call, though.
- _stephan 14y agoClose is annotated as a blocking syscall in http://golang.org/src/pkg/syscall/syscall_linux.go#L810 http://golang.org/src/pkg/syscall/syscall_linux.go#L810 Is there a guarantee on Linux that close can't block? (I suppose it depends on the file type and the definition of blocking.)
- tptacek 14y agoOnly if SO_LINGER is set.