Re: [go-nuts] Is this implementation of weak pointers safe?

Why do you want a weak pointer? What for? -- 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

Re: [go-nuts] Is this implementation of weak pointers safe?

On Saturday, September 29, 2018 at 2:49:19 PM UTC-5, Ian Denhardt wrote: > > Quoting Ben Lubar (2018-09-29 14:40:28) > >[1]https://play.golang.org/p/iBAii-f84Sq > >vet is complaining because the unsafe.Pointer usage would normally be > >dangerous around the garbage collector, but

Re: [go-nuts] using 'go function_call()' inside Go program

On Sun, Sep 30, 2018 at 3:47 PM Hemant Singh wrote: > I have a question. I have changed the open goping.go code to return error > from functions. > > The following function is implemented in a .goping.go file. > > func ping(config *Config, address, name string, pattern *regexp.Regexp) > error {

[go-nuts] using 'go function_call()' inside Go program

I have a question. I have changed the open goping.go code to return error from functions. The following function is implemented in a .goping.go file. func ping(config *Config, address, name string, pattern *regexp.Regexp) error { } Another function shown below, in the same .go file, calls

[go-nuts] cgo use question

Howdy Gophers, I've a got cgo question. Suppose I want to use cgo in 2 packages and have one C function used in C code in both packages. Is there a way to do this with the go tool only? I am trying to avoid a build that needs make or the like to build a c library, or copying and renaming the

[go-nuts] Re: Are C allocated memory completely isolated to Go memory in any cases?

Not sure if it would be of any help, but maybe you can gleem some insight from the way these packages did things? https://github.com/mattn/go-gtk https://github.com/gotk3/gotk3 -K -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe

Re: [go-nuts] Is this implementation of weak pointers safe?

Quoting Ben Lubar (2018-09-29 14:40:28) >[1]https://play.golang.org/p/iBAii-f84Sq >vet is complaining because the unsafe.Pointer usage would normally be >dangerous around the garbage collector, but since I have a finalizer on >the "real" pointer and there is no way the code could

[go-nuts] Is this implementation of weak pointers safe?

https://play.golang.org/p/iBAii-f84Sq vet is complaining because the unsafe.Pointer usage would normally be dangerous around the garbage collector, but since I have a finalizer on the "real" pointer and there is no way the code could access the uintptr with the same value as the real pointer

Re: [go-nuts] go mod tidy pulls in too much

As a followup, I have been informed that there is a related open issue which seems like a good place to direct followup https://github.com/golang/go/issues/26955 Best,

Re: [go-nuts] Are C allocated memory completely isolated to Go memory in any cases?

On Fri, 28 Sep 2018 22:27:04 -0700 (PDT) changkun wrote: > Not really, the original C code calls pango in every new created thread. > [...] > the Pango call is always called in a newly created thread. IIUC its your old C code spinning a new thread for each Pango call (?). If so, you should not

Re: [go-nuts] Are C allocated memory completely isolated to Go memory in any cases?

2018. szeptember 29., szombat 17:10:25 UTC+2 időpontban changkun a következőt írta: > > > > On Saturday, September 29, 2018 at 4:03:42 PM UTC+2, Tamás Gulácsi wrote: >> >> Create One (1) goroutine with LockOSThread and let it get the todo and >> response channel from a channel and send the

Re: [go-nuts] go mod tidy pulls in too much

Hi Scott, Regarding your comment, a related issue (which is still open) is this one: #26955: “cmd/go: provide straightforward way to see non-test dependencies” https://github.com/golang/go/issues/26955 —thepudds -- You received this message because you are subscribed to the Google

Re: [go-nuts] go mod tidy pulls in too much

Hi Scott, Regarding your comment, a related issue (which is still open) is this one: #26955: “cmd/go: provide straightforward way to see non-test dependencies” https://github.com/golang/go/issues/26955 --thepudds Terseness courtesy of my mobile device >

Re: [go-nuts] Are C allocated memory completely isolated to Go memory in any cases?

On Saturday, September 29, 2018 at 4:03:42 PM UTC+2, Tamás Gulácsi wrote: > > Create One (1) goroutine with LockOSThread and let it get the todo and > response channel from a channel and send the response back when ready, and > make all other goroutines communicate with this one and only one

Re: [go-nuts] Are C allocated memory completely isolated to Go memory in any cases?

On Saturday, September 29, 2018 at 3:46:41 PM UTC+2, Robert Engels wrote: > > Your description makes no sense. Why are you creating another C thread, > you should just lock the OS thread the Go routine is on. Otherwise if you > create another C thread, in the cgo call you need to block that

Re: [go-nuts] Are C allocated memory completely isolated to Go memory in any cases?

Create One (1) goroutine with LockOSThread and let it get the todo and response channel from a channel and send the response back when ready, and make all other goroutines communicate with this one and only one pango-dedicated goroutine. Which is locked to a thread. -- You received this

Re: [go-nuts] go mod tidy pulls in too much

Hi all, I think this is related to https://github.com/golang/go/issues/26913 which is closed but still has commentary that seems unresolved after it was closed . Scott On Friday, 28 September 2018 20:11:29 UTC+2, Harmen wrote: > > On Fri, Sep 28, 2018 at 10:19:50AM -0700, thepud...@gmail.com

Re: [go-nuts] Are C allocated memory completely isolated to Go memory in any cases?

Your description makes no sense. Why are you creating another C thread, you should just lock the OS thread the Go routine is on. Otherwise if you create another C thread, in the cgo call you need to block that thread or somehow communicate back into Go some other way - otherwise what is the

Re: [go-nuts] Are C allocated memory completely isolated to Go memory in any cases?

On Saturday, September 29, 2018 at 2:08:03 PM UTC+2, Tamás Gulácsi wrote: > > Yes, but is that a one and only goroutine? No. The cgo call is opened for every new incoming user request. Let's summarize: - Every network request creates a goroutine without response processing result to a user

Re: [go-nuts] Are C allocated memory completely isolated to Go memory in any cases?

Yes, but is that a one and only goroutine? -- 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

Re: [go-nuts] Are C allocated memory completely isolated to Go memory in any cases?

As discussed before, the every pango call is called in a non-Go newly created thread by C. runtime.LockOSThread doesn't work. On Saturday, September 29, 2018 at 1:24:21 PM UTC+2, Tamás Gulácsi wrote: > > You should LockOSThread and process every pango-facing call in that > goroutine. -- You

Re: [go-nuts] Are C allocated memory completely isolated to Go memory in any cases?

You should LockOSThread and process every pango-facing call in that goroutine. -- 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

Re: [go-nuts] Unsupported File Format error while building for linux-amd64 on mac os

I've also found that multipass (https://github.com/CanonicalLtd/multipass) works well for running Ubuntu on different platforms FWIW. On Fri, 28 Sep 2018, 9:28 pm Tamás Gulácsi, wrote: > 2018. szeptember 28., péntek 15:59:14 UTC+2 időpontban Ankit Gupta a > következőt írta: >> >> Thanks Ian for

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

On 09/28/2018 03:14 PM, Peter Mogensen wrote: > In other words.. using a map as index into another datastructure without > the map values being considered by the garbage collector as references. I just quickly read about the java.util.WeakHashMap and it says that the keys are the weak

Re: [go-nuts] Huge map[string]*Object and GC where *Object is from sync.Pool

Please re-read what I was answering: "I know what a uintptr is but what would you put in it if not a pointer to another object?". If you have done that and still believe what I wrote is not true, please explain what I have got wrong. I am afraid I do not understand at all what you think is not