Re: [go-nuts] Access to variable names on goroutine stacks and on the heap in the runtime

[vaastav anand]

Ahh that makes sense thank you.

I think this file in Delve : 
https://github.com/go-delve/delve/blob/master/pkg/proc/bininfo.go does 
exactly what I need if I am not wrong.

On Wednesday, 10 April 2019 21:04:49 UTC-7, Ian Lance Taylor wrote:
>
> On Wed, Apr 10, 2019 at 5:27 PM vaastav anand  > wrote: 
> > 
> > > That is the bare bones of the DWARF information.  That will let you 
> > read the DWARF info, but it won't help you map PC and SP values to 
> > variable names. 
> > 
> > I am not sure why this is the case. I thought along with the dwarf info, 
> once I have the frame information for each goroutine's stack I could end up 
> mapping the values to the variables. This frame information is available 
> from runtime's Stack function in src/runtime/mprof.go 
> > Maybe I missed something? 
>
> I was unclear.  I don't mean that it can't be done.  I mean that you 
> will need a lot of code beyond what is provided by debug/dwarf. 
>
> > > Correct.  Heap variables don't have names at all in any case 
> > 
> > Ok, I am assuming anything on the heap is essentially referenced by the 
> pointer variable on the stack? 
>
> Yes, or by a global variable, and possibly indirectly via other pointers. 
>
> > Sorry, if the following is a stupid question : Do the global variables 
> have no name or is that something that is present in the debugging 
> information? (I used to think that the global variables would be somewhere 
> in the code segment and thus must have debugging info associated with it.) 
>
> Global variable names should be present in the debug info. 
>
> 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] Access to variable names on goroutine stacks and on the heap in the runtime

[Ian Lance Taylor]

On Wed, Apr 10, 2019 at 5:27 PM vaastav anand  wrote:
>
> > That is the bare bones of the DWARF information.  That will let you
> read the DWARF info, but it won't help you map PC and SP values to
> variable names.
>
> I am not sure why this is the case. I thought along with the dwarf info, once 
> I have the frame information for each goroutine's stack I could end up 
> mapping the values to the variables. This frame information is available from 
> runtime's Stack function in src/runtime/mprof.go
> Maybe I missed something?

I was unclear.  I don't mean that it can't be done.  I mean that you
will need a lot of code beyond what is provided by debug/dwarf.

> > Correct.  Heap variables don't have names at all in any case
>
> Ok, I am assuming anything on the heap is essentially referenced by the 
> pointer variable on the stack?

Yes, or by a global variable, and possibly indirectly via other pointers.

> Sorry, if the following is a stupid question : Do the global variables have 
> no name or is that something that is present in the debugging information? (I 
> used to think that the global variables would be somewhere in the code 
> segment and thus must have debugging info associated with it.)

Global variable names should be present in the debug info.

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] gcwaiting=1 will causes block all the goroutines?

[mountainfpf]

Thank you, brother, the following jake brothers helped me to bring out all 
the confusion.

在 2019年4月10日星期三 UTC+8下午9:31:41，Ian Lance Taylor写道：
>
> On Wed, Apr 10, 2019 at 4:52 AM > wrote: 
> > 
> > My  macos has 4 cores, but i start 3 goroutines, 2 sub goroutines, 1 
> main goroutine. 
> > After main goroutine  exec 3 times  output, triggering gc causes 
> gcwaiting=1. 
> > Finally all goroutine blocking 
> > 
> > package main 
> > 
> > import ( 
> > "fmt" 
> > "log" 
> > "net/http" 
> > _ "net/http/pprof" 
> > "runtime" 
> > 
> > // "runtime" 
> > "time" 
> > ) 
> > 
> > func deadloop() { 
> > for { 
> > } 
> > } 
> > func main() { 
> > go func() { 
> > log.Println(http.ListenAndServe("localhost:6060", nil)) 
> > }() 
> > 
> > go deadloop() 
> > 
> > i := 3 
> > for { 
> > time.Sleep(time.Second * 1) 
> > i-- 
> > fmt.Println("I got scheduled!") 
> > if i == 0 { 
> > runtime.GC() //will set gcwaiting=1， causes other goroutines not to be 
> scheduled 
> > } 
> > } 
> > } 
>
> I'm not sure quite what you are asking, but the garbage collector has 
> to briefly stop all goroutines twice each cycle, as described in the 
> comment in runtime/mgc.go. 
>
> 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.

[go-nuts] Re: gcwaiting=1 will causes block all the goroutines?

[mountainfpf]

Thank you very much for your meticulous reply. I basically understand the 
scheduling mechanism, but I still don’t understand the third paragraph.

It is  "It is also important to note that the behavior of runtime.GC() is 
not the exactly same as the normal backgound GC that gets run by the 
runtime. In particular runtime.GC() will block until GC is completed, 
whereas the noral gc does most of its work while allowing the program to 
continue running. "

在 2019年4月11日星期四 UTC+8上午12:12:01，jake...@gmail.com写道：
>
> As Ian said, your question is not completely clear. I think you are Saying 
> that "I got scheduled!" prints 3 times, then the program appears to "hangs" 
> on the runtime.GC() call.
>
> To start with, it is usually helpful to create a *minimal *program when 
> dealing with questions like this. Your program can be reduced to 
> https://play.golang.org/p/-9ekKOxyVoc:
> package main
>
> import (
> "fmt"
> "runtime"
> "time"
> )
>
> func deadloop() {
> for {
> //runtime.Gosched()
> }
> }
> func main() {
>
> go deadloop()
>
> i := 3
> for {
> time.Sleep(time.Second * 1)
> i--
> fmt.Println("I got scheduled!", i)
> if i == 0 {
> runtime.GC() //will set gcwaiting=1， causes other goroutines 
> not to be scheduled
> }
> }
> }
> This prints:
> I got scheduled! 2
> I got scheduled! 1
> I got scheduled! 0
> Then hangs. 
>
> I believe that what you are seeing is a result of the GC needing to 
> briefly pause all goroutines. Go uses something like cooperative 
> multithreading for goroutines. Your deadloop() function can not be 
> preempted under the current implentation of the go compiler. So the call to 
> runtime.GC() hangs waiting to pause all goroutines. If you un comment the 
> runtime.Gosched() call on line 11, then your program will work as expected. 
>
> The details of premtion are implementation dependant, and work is being 
> done to improve the situation. There is a lot of information available, but 
> if you have a long running loop that makes no function calls, then it is a 
> good idea to call runtime.Gosched() every so often.
>
> It is also important to note that the behavior of runtime.GC() is not the 
> exactly same as the normal backgound GC that gets run by the runtime. In 
> particular runtime.GC() will block until GC is completed, whereas the noral 
> gc does most of its work while allowing the program to continue running. 
>
> Hope that helps.
>
>
> On Wednesday, April 10, 2019 at 7:51:52 AM UTC-4, mount...@gmail.com 
> wrote:
>>
>> Hi,
>>
>> My  macos has 4 cores, but i start 3 goroutines, 2 sub goroutines, 1 main 
>> goroutine. 
>> After main goroutine  exec 3 times  output, triggering gc causes 
>> gcwaiting=1.
>> Finally all goroutine blocking
>>
>> package main
>>
>> import (
>> "fmt"
>> "log"
>> "net/http"
>> _ "net/http/pprof"
>> "runtime"
>>
>> // "runtime"
>> "time"
>> )
>>
>> func deadloop() {
>> for {
>> }
>> }
>> func main() {
>> go func() {
>> log.Println(http.ListenAndServe("localhost:6060", nil))
>> }()
>>
>> go deadloop()
>>
>> i := 3
>> for {
>> time.Sleep(time.Second * 1)
>> i--
>> fmt.Println("I got scheduled!")
>> if i == 0 {
>> runtime.GC() //will set gcwaiting=1， causes other goroutines not to be 
>> scheduled
>> }
>> }
>> }
>>
>

-- 
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] Access to variable names on goroutine stacks and on the heap in the runtime

[vaastav anand]

> That is the bare bones of the DWARF information.  That will let you 
read the DWARF info, but it won't help you map PC and SP values to 
variable names. 

I am not sure why this is the case. I thought along with the dwarf info, 
once I have the frame information for each goroutine's stack I could end up 
mapping the values to the variables. This frame information is available 
from runtime's Stack function in src/runtime/mprof.go
Maybe I missed something?

> Correct.  Heap variables don't have names at all in any case

Ok, I am assuming anything on the heap is essentially referenced by the 
pointer variable on the stack? 

Sorry, if the following is a stupid question : Do the global variables have 
no name or is that something that is present in the debugging information? 
(I used to think that the global variables would be somewhere in the code 
segment and thus must have debugging info associated with it.)

PS Thanks so much for all the help! I really do appreciate it.

On Wednesday, 10 April 2019 16:58:36 UTC-7, Ian Lance Taylor wrote:
>
> On Wed, Apr 10, 2019 at 4:34 PM vaastav anand  > wrote: 
> > 
> > Is the debug info exported in the binary in DWARF format? 
>
> Yes. 
>
> > And if so would this package work https://golang.org/pkg/debug/dwarf/? 
>
> That is the bare bones of the DWARF information.  That will let you 
> read the DWARF info, but it won't help you map PC and SP values to 
> variable names. 
>
> > What about the global variables or the ones allocated on the heap? Are 
> they also not available inside the runtime either? 
>
> Correct.  Heap variables don't have names at all in any case. 
>
> Ian 
>
> > On Wednesday, 10 April 2019 13:28:49 UTC-7, Ian Lance Taylor wrote: 
> >> 
> >> On Tue, Apr 9, 2019 at 7:43 AM  wrote: 
> >> > 
> >> > I have been working on a research project where I have been modifying 
> the runtime such that I can control the goroutines that are scheduled as 
> well as get access to the values of program variables. 
> >> > I know I can access the stack through the g struct for a goroutine 
> but I was wondering if someone could tell me how to get the symbol/object 
> table so that I can figure out the names of the local variables on the 
> stack for the goroutine as well as the variables on the heap. 
> >> > Any help would be greatly appreciated. 
> >> 
> >> The names of local variables on the stack are recorded only the debug 
> >> information, which is not loaded into memory.  You would need to 
> >> locate the binary, open it, and look at the debug info.  Getting a 
> >> local variable name from the debug info is complex, but Delve and gdb 
> >> manage to do it. 
> >> 
> >> That is, getting the names of local variables is technically possible 
> >> but quite hard.  I wouldn't recommend this approach. 
> >> 
> >> 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 golan...@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] Access to variable names on goroutine stacks and on the heap in the runtime

[Ian Lance Taylor]

On Wed, Apr 10, 2019 at 4:34 PM vaastav anand  wrote:
>
> Is the debug info exported in the binary in DWARF format?

Yes.

> And if so would this package work https://golang.org/pkg/debug/dwarf/?

That is the bare bones of the DWARF information.  That will let you
read the DWARF info, but it won't help you map PC and SP values to
variable names.

> What about the global variables or the ones allocated on the heap? Are they 
> also not available inside the runtime either?

Correct.  Heap variables don't have names at all in any case.

Ian

> On Wednesday, 10 April 2019 13:28:49 UTC-7, Ian Lance Taylor wrote:
>>
>> On Tue, Apr 9, 2019 at 7:43 AM  wrote:
>> >
>> > I have been working on a research project where I have been modifying the 
>> > runtime such that I can control the goroutines that are scheduled as well 
>> > as get access to the values of program variables.
>> > I know I can access the stack through the g struct for a goroutine but I 
>> > was wondering if someone could tell me how to get the symbol/object table 
>> > so that I can figure out the names of the local variables on the stack for 
>> > the goroutine as well as the variables on the heap.
>> > Any help would be greatly appreciated.
>>
>> The names of local variables on the stack are recorded only the debug
>> information, which is not loaded into memory.  You would need to
>> locate the binary, open it, and look at the debug info.  Getting a
>> local variable name from the debug info is complex, but Delve and gdb
>> manage to do it.
>>
>> That is, getting the names of local variables is technically possible
>> but quite hard.  I wouldn't recommend this approach.
>>
>> 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.

-- 
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] Access to variable names on goroutine stacks and on the heap in the runtime

[vaastav anand]

Is the debug info exported in the binary in DWARF format? And if so would 
this package work https://golang.org/pkg/debug/dwarf/?
What about the global variables or the ones allocated on the heap? Are they 
also not available inside the runtime either?

On Wednesday, 10 April 2019 13:28:49 UTC-7, Ian Lance Taylor wrote:
>
> On Tue, Apr 9, 2019 at 7:43 AM > 
> wrote: 
> > 
> > I have been working on a research project where I have been modifying 
> the runtime such that I can control the goroutines that are scheduled as 
> well as get access to the values of program variables. 
> > I know I can access the stack through the g struct for a goroutine but I 
> was wondering if someone could tell me how to get the symbol/object table 
> so that I can figure out the names of the local variables on the stack for 
> the goroutine as well as the variables on the heap. 
> > Any help would be greatly appreciated. 
>
> The names of local variables on the stack are recorded only the debug 
> information, which is not loaded into memory.  You would need to 
> locate the binary, open it, and look at the debug info.  Getting a 
> local variable name from the debug info is complex, but Delve and gdb 
> manage to do it. 
>
> That is, getting the names of local variables is technically possible 
> but quite hard.  I wouldn't recommend this approach. 
>
> 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] Access to variable names on goroutine stacks and on the heap in the runtime

[Ian Lance Taylor]

On Tue, Apr 9, 2019 at 7:43 AM  wrote:
>
> I have been working on a research project where I have been modifying the 
> runtime such that I can control the goroutines that are scheduled as well as 
> get access to the values of program variables.
> I know I can access the stack through the g struct for a goroutine but I was 
> wondering if someone could tell me how to get the symbol/object table so that 
> I can figure out the names of the local variables on the stack for the 
> goroutine as well as the variables on the heap.
> Any help would be greatly appreciated.

The names of local variables on the stack are recorded only the debug
information, which is not loaded into memory.  You would need to
locate the binary, open it, and look at the debug info.  Getting a
local variable name from the debug info is complex, but Delve and gdb
manage to do it.

That is, getting the names of local variables is technically possible
but quite hard.  I wouldn't recommend this approach.

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] how to use an instance across functions in a package w/o global vars

[Dumitru Ungureanu]

In this particular case, w.DefineFunction Api does not acomodate such a 
passing. Reason I asked in the first place. Dependency injection of what sort 
can be used here...

-- 
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] Re: Easy to use (getopt based) flags package

[Tong Sun]

take a look at

https://github.com/mkideal/cli

It's declarative, generate help-text/usage for you, and support sub 
commands, and even sub sub commands. 

just + my 2c.


On Wednesday, April 10, 2019 at 6:59:37 AM UTC-4, mhh...@gmail.com wrote:
>
> looks lovely, how do you manage sub commands ?
>
> On Wednesday, April 10, 2019 at 2:24:21 AM UTC+2, Paul Borman wrote:
>>
>> I have never been quite happy with the flags packages available for Go, 
>> including the standard flags package as well as my own getopt packages (v1 
>> and v2).  They are just too cumbersome to use.  I finally have come up with 
>> a solution that I like.  github.com/pborman/options 
>> 
>>
>> The command line options are declared as a simple structure with struct 
>> tags, for example:
>>
>> // Declare the command line flags.  The help information does not need to 
>> line up,
>> // I just think it looks prettier this way.
>> var opts = struct {
>> Helpoptions.Help  `getopt:"--help   display help"`
>> Namestring`getopt:"--name=NAME  name of the widget"`
>> Count   int   `getopt:"--count -c=COUNT number of widgets"`
>> Verbose bool  `getopt:"-v   be verbose"`
>> Timeout time.Duration `getopt:"--timeoutduration of run"`
>> }{
>> Name: “gopher”,
>> }
>>
>> func main() {
>> // Assign args to the positional parameters.
>> args := options.RegisterAndParse(&opts)
>>
>> fmt.Printf(“Name is: %s\n”, opts.Name)
>> …
>> }
>>
>> The command usage displayed by passing —help to the above program will 
>> look something like:
>>
>> Usage: prog [-v] [-c COUNT] [--help] [--name NAME] [--timeout value] 
>> [parameters ...]
>>  -c, --count=COUNT  number of widgets
>>  --help display help
>>  --name=NAMEname of the widget [gopher]
>>  --timeout=value
>> duration of run
>>  -v be verbose
>>
>> The package is built on top of the github.com/pborman/getopt/v2 
>>  package and as such 
>> they can be used together.  The options package also supports reading 
>> command line arguments from a file by using the options.Flags type.
>>
>> I hope that some of you might find this helpful in writing command line 
>> programs.
>>
>> -Paul
>>
>

-- 
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] Re: Easy to use (getopt based) flags package

['Borman, Paul' via golang-nuts]

Thank you!

It does handle subcommands, I should write an example of that.  In short, you 
use RegisterNew to create a new getopt.Set or RegisterSet to register with a 
previously created set.  You will have to call set.Parse to parse the args to 
the subcommand.  If you need to parse a particular set multiple times that has 
default values then you will want to use Dup.  Also, you probably want a named 
structure.  Something like this (beware, I have not compiled this code):

Example with no global defaults
type cmdOpts struct { … }

 v, set := options.RegisterNew(“command”, &cmdOpts{})
 opts := v.(*cmdOpts)
 set.Parse(args)

Example with global and local defaults:
type cmdOpts struct {
Namestring`getopt:"--name=NAME  name of the widget"`
Count   int   `getopt:"--count -c=COUNT number of widgets"`
}
var cmdGlobalOpts = &cmdOpts {
 Name: “global”,
}

opts := options.Dup(&cmdGlobalOpts).(*cmdOpts)
opts.Count = 42
 v, set := options.RegisterNew(“command”, opts)
 set.Parse(args)

I will try to get an example added to the codebase in the next week or so.

BTW, my hope is that in most common cases you can just use the options 
packages.  You can also use github.com/pborman/getopt/v2 in conjunction with 
the options package if need be.

-Paul

From:  on behalf of "mhhc...@gmail.com" 

Date: Wednesday, April 10, 2019 at 4:00 AM
To: golang-nuts 
Subject: [go-nuts] Re: Easy to use (getopt based) flags package

looks lovely, how do you manage sub commands ?

On Wednesday, April 10, 2019 at 2:24:21 AM UTC+2, Paul Borman wrote:
I have never been quite happy with the flags packages available for Go, 
including the standard flags package as well as my own getopt packages (v1 and 
v2).  They are just too cumbersome to use.  I finally have come up with a 
solution that I like.  
github.com/pborman/options

The command line options are declared as a simple structure with struct tags, 
for example:

// Declare the command line flags.  The help information does not need to line 
up,
// I just think it looks prettier this way.
var opts = struct {
Helpoptions.Help  `getopt:"--help   display help"`
Namestring`getopt:"--name=NAME  name of the widget"`
Count   int   `getopt:"--count -c=COUNT number of widgets"`
Verbose bool  `getopt:"-v   be verbose"`
Timeout time.Duration `getopt:"--timeoutduration of run"`
}{
Name: “gopher”,
}

func main() {
// Assign args to the positional parameters.
args := options.RegisterAndParse(&opts)

fmt.Printf(“Name is: %s\n”, opts.Name)
…
}

The command usage displayed by passing —help to the above program will look 
something like:

Usage: prog [-v] [-c COUNT] [--help] [--name NAME] [--timeout value] 
[parameters ...]
 -c, --count=COUNT  number of widgets
 --help display help
 --name=NAMEname of the widget [gopher]
 --timeout=value
duration of run
 -v be verbose
The package is built on top of the 
github.com/pborman/getopt/v2 
package and as such they can be used together.  The options package also 
supports reading command line arguments from a file by using the options.Flags 
type.

I hope that some of you might find this helpful in writing command line 
programs.

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

-- 
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] Re: gcwaiting=1 will causes block all the goroutines?

[jake6502]

As Ian said, your question is not completely clear. I think you are Saying 
that "I got scheduled!" prints 3 times, then the program appears to "hangs" 
on the runtime.GC() call.

To start with, it is usually helpful to create a *minimal *program when 
dealing with questions like this. Your program can be reduced to 
https://play.golang.org/p/-9ekKOxyVoc:
package main

import (
"fmt"
"runtime"
"time"
)

func deadloop() {
for {
//runtime.Gosched()
}
}
func main() {

go deadloop()

i := 3
for {
time.Sleep(time.Second * 1)
i--
fmt.Println("I got scheduled!", i)
if i == 0 {
runtime.GC() //will set gcwaiting=1， causes other goroutines 
not to be scheduled
}
}
}
This prints:
I got scheduled! 2
I got scheduled! 1
I got scheduled! 0
Then hangs. 

I believe that what you are seeing is a result of the GC needing to briefly 
pause all goroutines. Go uses something like cooperative multithreading for 
goroutines. Your deadloop() function can not be preempted under the current 
implentation of the go compiler. So the call to runtime.GC() hangs waiting 
to pause all goroutines. If you un comment the runtime.Gosched() call on 
line 11, then your program will work as expected. 

The details of premtion are implementation dependant, and work is being 
done to improve the situation. There is a lot of information available, but 
if you have a long running loop that makes no function calls, then it is a 
good idea to call runtime.Gosched() every so often.

It is also important to note that the behavior of runtime.GC() is not the 
exactly same as the normal backgound GC that gets run by the runtime. In 
particular runtime.GC() will block until GC is completed, whereas the noral 
gc does most of its work while allowing the program to continue running. 

Hope that helps.


On Wednesday, April 10, 2019 at 7:51:52 AM UTC-4, mount...@gmail.com wrote:
>
> Hi,
>
> My  macos has 4 cores, but i start 3 goroutines, 2 sub goroutines, 1 main 
> goroutine. 
> After main goroutine  exec 3 times  output, triggering gc causes 
> gcwaiting=1.
> Finally all goroutine blocking
>
> package main
>
> import (
> "fmt"
> "log"
> "net/http"
> _ "net/http/pprof"
> "runtime"
>
> // "runtime"
> "time"
> )
>
> func deadloop() {
> for {
> }
> }
> func main() {
> go func() {
> log.Println(http.ListenAndServe("localhost:6060", nil))
> }()
>
> go deadloop()
>
> i := 3
> for {
> time.Sleep(time.Second * 1)
> i--
> fmt.Println("I got scheduled!")
> if i == 0 {
> runtime.GC() //will set gcwaiting=1， causes other goroutines not to be 
> scheduled
> }
> }
> }
>

-- 
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] gcwaiting=1 will causes block all the goroutines?

[Ian Lance Taylor]

On Wed, Apr 10, 2019 at 4:52 AM  wrote:
>
> My  macos has 4 cores, but i start 3 goroutines, 2 sub goroutines, 1 main 
> goroutine.
> After main goroutine  exec 3 times  output, triggering gc causes gcwaiting=1.
> Finally all goroutine blocking
>
> package main
>
> import (
> "fmt"
> "log"
> "net/http"
> _ "net/http/pprof"
> "runtime"
>
> // "runtime"
> "time"
> )
>
> func deadloop() {
> for {
> }
> }
> func main() {
> go func() {
> log.Println(http.ListenAndServe("localhost:6060", nil))
> }()
>
> go deadloop()
>
> i := 3
> for {
> time.Sleep(time.Second * 1)
> i--
> fmt.Println("I got scheduled!")
> if i == 0 {
> runtime.GC() //will set gcwaiting=1， causes other goroutines not to be 
> scheduled
> }
> }
> }

I'm not sure quite what you are asking, but the garbage collector has
to briefly stop all goroutines twice each cycle, as described in the
comment in runtime/mgc.go.

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] how to use an instance across functions in a package w/o global vars

[Jan Mercl]

On Wed, Apr 10, 2019 at 2:42 PM Dumitru Ungureanu  wrote:

The alternative is to pass `w` around as a function argument. For that
it will be necessary to create/initialize `w` in main or in a function
call made from main.

PS: Go has no global scope. The closest is universe scope, but
programs cannot define anything in universe scope. The scope of `w` in
the OP is called package scope.

-- 
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] how to use an instance across functions in a package w/o global vars

[Dumitru Ungureanu]

I have this.

Enter code here...
package main

import (
"fmt"
"log"

"github.com/sciter-sdk/go-sciter"
"github.com/sciter-sdk/go-sciter/window"
)

var w *window.Window

func init() {
var err error
w, err = window.New(sciter.DefaultWindowCreateFlag, sciter.DefaultRect)

if err != nil {
log.Fatal(err)
}
}

func main() {
w.SetResourceArchive(resources)
w.LoadFile("this://app/conect.html")

w.DefineFunction("goConect", goConect)

w.Show()
w.Run()
}

func goConect(vals ...*sciter.Value) *sciter.Value {
fmt.Print(vals)
w.LoadFile("this://app/cauta.html")
return nil
}

Can var w *window.Window be avoided?

-- 
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] Problem serving http after hiding directory listings

[Luis P. Mendes]

My simple web application was working fine, except for the part that it was 
showing directory listings, which I'd like to avoid.

After searching, came to this solution
https://groups.google.com/forum/#!msg/golang-nuts/bStLPdIVM6w/hidTJgDZpHcJ
using a virtual file-system.


My app has the following structure
~/go
|
|___ go binary (or go source files)
|
|___ static/css, static/js, static/images
|
|___ html/ where index.html, kit1.html, other html files are

This was working fine, but a user could point to http://mysite/static and 
get a directory listing which I’d like to prevent.

Tried to adapt my code to that virtual filesystem solution above:

func main() {
 //fs := http.FileServer(http.Dir("static/"))(old, working)




 http.HandleFunc("/", indexHandler)
 http.HandleFunc("/kit1", indexHandler)


 fs := justFilesFilesystem{http.Dir("")}
 http.Handle("/static/", http.StripPrefix("/static/", http.FileServer(fs)))
 log.Fatal(http.ListenAndServe(":8090", http.FileServer(fs)))   // 
second parameter was nil before
}


type justFilesFilesystem struct {
 fs http.FileSystem
}


func (fs justFilesFilesystem) Open(name string) (http.File, error) {
 f, err := fs.fs.Open(name)
 if err != nil {
 return nil, err
 }
 return neuteredReaddirFile{f}, nil
}


type neuteredReaddirFile struct {
 http.File
}


func (f neuteredReaddirFile) Readdir(count int) ([]os.FileInfo, error) {
 return nil, nil
}



The handler begins with

func indexHandler(w http.ResponseWriter, r *http.Request) {

path, err := filepath.Abs(filepath.Dir(os.Args[0]))
// error checking surpressed

switch r.Method {
case "GET":
   f := urlToFile(r.URL.Path)
   fmt.Println("f: ", f)
   if f == "" {
   f = "index.html"
   }
   fmt.Println("f_after: ", f)
   http.ServeFile(w, r, "html/"+f)


Although it seems to load around 150Kb, it shows a blank page having just




If `index.html` is copied from html/index.html to /home/lupe/go/ the server 
renders it.

The function `indexHandler` doesn’t seem to be called whenever `/`, 
`index.html` or `/kit1.html` is chosen, as the `fmt.Println` function 
doesn't print anything on the console.

Without changing the html/ and static/ files locations, what changes should 
I do to the code?

-- 
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] Generics of Kith and Kin

[Mandolyte]

I don't believe anyone has mentioned how a muon does generics... muon claims to 
be inspired by Go and some others; and indeed it feels familiar. At any rate, 
just for information and interest:
https://github.com/nickmqb/muon/blob/master/docs/muon_by_example.md#generic-structs
 

-- 
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] gcwaiting=1 will causes block all the goroutines?

[mountainfpf]

Hi,

My  macos has 4 cores, but i start 3 goroutines, 2 sub goroutines, 1 main 
goroutine. 
After main goroutine  exec 3 times  output, triggering gc causes 
gcwaiting=1.
Finally all goroutine blocking

package main

import (
"fmt"
"log"
"net/http"
_ "net/http/pprof"
"runtime"

// "runtime"
"time"
)

func deadloop() {
for {
}
}
func main() {
go func() {
log.Println(http.ListenAndServe("localhost:6060", nil))
}()

go deadloop()

i := 3
for {
time.Sleep(time.Second * 1)
i--
fmt.Println("I got scheduled!")
if i == 0 {
runtime.GC() //will set gcwaiting=1， causes other goroutines not to be 
scheduled
}
}
}

-- 
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] Re: Easy to use (getopt based) flags package

[mhhcbon]

looks lovely, how do you manage sub commands ?

On Wednesday, April 10, 2019 at 2:24:21 AM UTC+2, Paul Borman wrote:
>
> I have never been quite happy with the flags packages available for Go, 
> including the standard flags package as well as my own getopt packages (v1 
> and v2).  They are just too cumbersome to use.  I finally have come up with 
> a solution that I like.  github.com/pborman/options 
> 
>
> The command line options are declared as a simple structure with struct 
> tags, for example:
>
> // Declare the command line flags.  The help information does not need to 
> line up,
> // I just think it looks prettier this way.
> var opts = struct {
> Helpoptions.Help  `getopt:"--help   display help"`
> Namestring`getopt:"--name=NAME  name of the widget"`
> Count   int   `getopt:"--count -c=COUNT number of widgets"`
> Verbose bool  `getopt:"-v   be verbose"`
> Timeout time.Duration `getopt:"--timeoutduration of run"`
> }{
> Name: “gopher”,
> }
>
> func main() {
> // Assign args to the positional parameters.
> args := options.RegisterAndParse(&opts)
>
> fmt.Printf(“Name is: %s\n”, opts.Name)
> …
> }
>
> The command usage displayed by passing —help to the above program will 
> look something like:
>
> Usage: prog [-v] [-c COUNT] [--help] [--name NAME] [--timeout value] 
> [parameters ...]
>  -c, --count=COUNT  number of widgets
>  --help display help
>  --name=NAMEname of the widget [gopher]
>  --timeout=value
> duration of run
>  -v be verbose
>
> The package is built on top of the github.com/pborman/getopt/v2 
>  package and as such they 
> can be used together.  The options package also supports reading command 
> line arguments from a file by using the options.Flags type.
>
> I hope that some of you might find this helpful in writing command line 
> programs.
>
> -Paul
>

-- 
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] Why will it deadlock if a goroutine acquire a mutex while pinned to its P?

[Cholerae Hu]

Thanks austin! I totally understand.

在 2019年4月9日星期二 UTC+8下午10:59:37，Austin Clements写道：
>
> Acquiring a mutex while pinned can cause deadlock because pinning prevents 
> a stop-the-world. For example, the following sequence could result in a 
> deadlock:
>
> M1: Acquires mutex l.
> M2: Pins the M.
> M2: Attempts to acquire mutex l.
> M3: Initiates stop-the-world
> M3: Stops M1
> M3: Attempts to stop M2, but can't because M2 is pinned.
>
> At this point, M1 can't make progress to release mutex l because M3 
> stopped it, which means M2 won't be able to finish acquiring the mutex (so 
> it will never release the pin), which means M3 won't be able to finish 
> stopping the world (so it will never start M1 back up).
>
> On Mon, Apr 8, 2019 at 2:31 AM Cholerae Hu  > wrote:
>
>> I'm reading this commit 
>> https://github.com/golang/go/commit/d5fd2dd6a17a816b7dfd99d4df70a85f1bf0de31 
>> .  
>> Inside runtime_procPin we only increases the m.lock count, why will it 
>> cause deadlock when acquiring a mutex after pin?
>>
>> -- 
>> 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 golan...@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.