[go-nuts] Alternative way of setting cgocheck=0
Hello, Is there any programmatic way of disabling cgo runtime checks? The documentation says to set environment variable "GODEBUG=cgocheck=0". However, this does not work for me as I do not control the environment. Hoping there is a programmatic way for disabling the runtime checks? Regards, Srimanth -- 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.
[go-nuts] runtime.LockOSThread() question
Hello, 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? Regards, Srimanth -- 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.
Re: [go-nuts] runtime.LockOSThread() question
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 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 > > 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] runtime.LockOSThread() question
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 > > 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 > >> 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 . > > 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.
Re: [go-nuts] runtime.LockOSThread() question
I have another code snippet which hits the same problem and it does not use sleep: https://play.golang.org/p/mUPCOFle4h All 10 goroutines are going beyond "runtime.LockOSThread()" on a single OS thread. Output: > main > locked 1 > locked 10 > locked 9 > locked 8 > locked 7 > locked 6 > locked 5 > locked 4 > locked 3 > locked 2 > done 1 > done 6 > done 4 > done 8 > done 7 > done 2 > done 9 > done 5 > done 3 > done 10 Thank you very much for looking into this. 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 > > 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 > >> 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 . > > 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.
