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

2018-09-29 Thread Tamás Gulácsi
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 https:

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

2018-09-29 Thread Ben Lubar
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 sin

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

2018-09-29 Thread Justin Israel
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

2018-09-29 Thread Hemant Singh
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

2018-09-29 Thread Scott Cotton
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?

2018-09-29 Thread K Davidson
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?

2018-09-29 Thread Ian Denhardt
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 ac

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

2018-09-29 Thread Ben Lubar
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 on

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

2018-09-29 Thread Scott Cotton
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

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

2018-09-29 Thread Wojciech S. Czarnecki
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 b

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

2018-09-29 Thread Tamás Gulácsi
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 respo

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

2018-09-29 Thread thepudds1460
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 Groups

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

2018-09-29 Thread t hepudds
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 > On

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

2018-09-29 Thread changkun
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?

2018-09-29 Thread changkun
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 thr

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

2018-09-29 Thread Tamás Gulácsi
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 messag

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

2018-09-29 Thread Scott Cotton
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?

2018-09-29 Thread Robert Engels
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 poin

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

2018-09-29 Thread changkun
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?

2018-09-29 Thread Tamás Gulácsi
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 http

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

2018-09-29 Thread changkun
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 r

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

2018-09-29 Thread Tamás Gulácsi
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 golang-nuts+unsubscr...@googlegroup

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

2018-09-29 Thread roger peppe
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

2018-09-29 Thread Peter Mogensen
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 reference

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

2018-09-29 Thread Dan Kortschak
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 tr