Thank you for pointing that out. 

Do you mean to say that as long as the process is running instructions, it 
will not let any other goroutine use that OS thread and execute?
If so, can the documentation be updated to mention sleeping as cause for 
letting other goroutines in.

Also, what other calls can result in other goroutines being used? Would a 
network call waiting for IO result in a goroutine context switch?

Thanks in advance.





On Monday, October 3, 2016 at 12:15:18 PM UTC-7, Ian Lance Taylor wrote:
>
> On Mon, Oct 3, 2016 at 12:10 PM, 'SrimanthG' via golang-nuts 
> <golan...@googlegroups.com <javascript:>> wrote: 
> > If you run the code snippet I pasted in 
> https://play.golang.org/p/4R-WlCiKNT 
> > you will see that it runs both in parallel - hence my confusion 
>
> Sleeping in time.Sleep does not count as running. 
>
> If you mean something else, can you be more specific?  My apologies if 
> I'm missing something. 
>
> Ian 
>
> > On Monday, October 3, 2016 at 12:04:39 PM UTC-7, Ian Lance Taylor wrote: 
> >> 
> >> On Mon, Oct 3, 2016 at 11:31 AM, 'SrimanthG' via golang-nuts 
> >> <golan...@googlegroups.com> wrote: 
> >> > 
> >> > I ran a Go program with GOMAXPROCS=1 and two goroutines which both 
> did 
> >> > "runtime.LockOSThread()" and slept 10 seconds before exiting. 
> >> > 
> >> > Code: https://play.golang.org/p/4R-WlCiKNT 
> >> > 
> >> > Since I had 1 OS thread and 2 goroutines trying to lock an OS thread, 
> I 
> >> > was 
> >> > expecting only one of them to complete first before the other one 
> >> > started... 
> >> > because the documentation said "Until the calling goroutine exits or 
> >> > calls 
> >> > UnlockOSThread, it will always execute in that thread, and no other 
> >> > goroutine can." 
> >> > 
> >> > However the output shows that both goroutines execute in parallel, 
> >> > contradicting LockOSThread documentation. 
> >> > Can someone explain if the documentation is wrong, if its a bug, or a 
> >> > better 
> >> > way to understand how these constructs work? 
> >> 
> >> GOMAXPROCS set a limit on the number of goroutines that may run in 
> >> parallel.  It does not set any sort of limit on the number of threads 
> >> that may exist.  You have two threads, which is fine.  All that 
> >> setting GOMAXPROCS=1 does is request the scheduler to only run one of 
> >> those threads at a time. 
> >> 
> >> Ian 
> > 
> > -- 
> > 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...@googlegroups.com <javascript:>. 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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.

Reply via email to