I have read some discussion on the release of OS-threads and it seems like
a difficult problem to solve. I don't think this comes up as a problem too
often though. Perhaps in very resource-limited systems?
tirsdag 23. august 2016 23.39.28 UTC+2 skrev Dave Cheney følgende:
>
> Approximately yes.
Approximately yes. However threads are not reclaimed by the runtime, so the
number of threads in a go program represents a high water mark, not necessarily
the current sum of active goroutines plus blocked syscall/cgo operations.
--
You received this message because you are subscribed to the G
Thank you for the clarification Ian.
So to sum up: the reason for the number of threads being more than
GOMAXPROCS, is that a thread has been in a syscall or blocking state,
perhaps due to opening a file or some I/O operation, and the runtime has
spawned a new OS-thread to maintain GOMAXPROCS-
On Tue, Aug 23, 2016 at 1:54 AM, Lars Kulseng wrote:
>
> I have tried to find some onformation about how OS-threads are created, and
> what their roles are. I know that this doesn't really matter in a lot of
> cases since goroutines are multiplexed on top of OS-threads and they are
> usually creat
I have tried to find some onformation about how OS-threads are created, and
what their roles are. I know that this doesn't really matter in a lot of
cases since goroutines are multiplexed on top of OS-threads and they are
usually created at startup of the program, but I'm just trying to
underst
