Don't worry, Gosched does what you want. I believe that "execution resumes automatically" is in the docs just to clarify that the goroutine is not suspended waiting for something and that no other action is required to wake up a goroutine that calls Gosched.
On Saturday, June 25, 2016 at 11:23:03 PM UTC+2, Kyle Stanly wrote: > > 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.
