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

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 >

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

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

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

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

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

> 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

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

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

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

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,

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

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

Re: [go-nuts] how to use an instance across functions in a package w/o global vars

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

[go-nuts] Re: Easy to use (getopt based) flags package

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

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

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

Re: [go-nuts] how to use an instance across functions in a package w/o global vars

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

[go-nuts] how to use an instance across functions in a package w/o global vars

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)

[go-nuts] Problem serving http after hiding directory listings

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

[go-nuts] Generics of Kith and Kin

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

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

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"

[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

Re: [go-nuts] Why will it deadlock if a goroutine acquire a mutex while pinned to its P?

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.