What I mean is, if I wish to yield to allow another Goroutine to run, why
would it "execution resume automatically"? I would expect it to immediately
give up it's time-slice, put itself at the end of the processor's 'p'
run-queue, and thats it. Does it only yield the processor immediately after
it loses it's timeslice? If so, it's kind of... I dunno, useless in that
regard. What if we have other Goroutines waiting on the same processor? Are
they moved to another 'p'?
So, lets say you have 4 Processors, denoted 'p', and 1000 Goroutines, 'g',
running on an OS thread, 'm'...
'm'
|
'p' - - - - - -
| |
'g_r' 'g_1'
|
'g_2'
...
|
'g_N'
Now, 'g_r' denotes a running Goroutine. Multiply the above by 4 (1 for each
processor). If we want to have 'g_1' to 'g_N' to run, maybe because we have
nothing else to do inside of a tight loop, will the call to Gosched allow
just that?
If Gosched will not do that, will something like usleep(0) do what I want?
What I am asking, once again, is that all Goroutines held by 'p' are not
held from being run, and that 'g_r' is just put behind 'g_N' in the
runqueue (or maybe not explicitly at the end, doesn't matter where, it just
isn't running)
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
