Re: [go-nuts] libgo is more fast that grouting.

On Mon, 16 Mar 2020 20:13:10 +0800 "'Benjamin' via golang-nuts" wrote: > How do you all think about it? > IMO there's no such thing as "Go-style concurrency" if you don't have `select`, which doesn't looks like this library provides (as many others). —wagner -- You received this message

[go-nuts] Re: [ANN] Gio: portable immediate mode GUI programs in Go for iOS/tvOS, Android, macOS, Linux, Windows

As an addition to Elias' examples, I wrote a little hello world++ here. https://github.com/glycerine/hello_gio -- 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] Re: Mem-Leak in Go method

In the single Go routine, use LockOSThread(). Then it was always be accessed on the same thread removing the memory synchronization problems. > On Mar 16, 2020, at 11:28 AM, Nitish Saboo wrote: > >  > Hi, > > So finally I got a little hint of the problem from what Robert described >

Re: [go-nuts] Re: Mem-Leak in Go method

Hi, So finally I got a little hint of the problem from what Robert described earlier in the mail. Thank you so much Robert. Looks like patterndb instance is not getting freed. node.c - PatternDB *patterndb; int load_pattern_db(const gchar* file, key_value_cb cb) { if(patterndb !=

[go-nuts] libgo is more fast that grouting.

I find a project that is very interesting, https://github.com/yyzybb537/libgo How do you all think about it? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving

Re: [go-nuts] Re: Mem-Leak in Go method

Hi Robert, Sorry I did not understand your point completely. I have a global variable patterndb on C side and It is getting called from a single goroutine every 3 mins. Why do I need to synchronize it? Even though the goroutine gets pinned to different threads, it can access the same global

Re: [go-nuts] Re: Mem-Leak in Go method

Yes, you have a shared global variable you need to synchronize. > On Mar 16, 2020, at 9:35 AM, Nitish Saboo wrote: > >  > Hi, > > Are you saying it is working as expected? > > Thanks, > Nitish > >> On Mon, Mar 16, 2020 at 7:42 PM Volker Dobler >> wrote: >>> On Monday, 16 March 2020

Re: [go-nuts] Mem-Leak in Go method

Because the same Go routine doesn’t mean it will be called on the same thread. It is essentially a race condition. I could be wrong - I’m sure someone will correct me. :) > On Mar 16, 2020, at 9:32 AM, Nitish Saboo wrote: > >  > Hi Robert, > > Looks like pattern_db is a global. Are you sure

Re: [go-nuts] Re: Mem-Leak in Go method

Hi, Are you saying it is working as expected? Thanks, Nitish On Mon, Mar 16, 2020 at 7:42 PM Volker Dobler wrote: > On Monday, 16 March 2020 14:25:52 UTC+1, Nitish Saboo wrote: >> >> Hi, >> >> I upgraded the go version and compiled the binary against go version 'go >> version go1.12.4

Re: [go-nuts] Mem-Leak in Go method

Hi Robert, Looks like pattern_db is a global. Are you sure you don’t have multiple Go routines calling the load? The global changes may not be visible- so the free is doing nothing. patterndb is a global variable on C side.load method is getting called from a single go routine every 3 mins.I

Re: [go-nuts] Mem-Leak in Go method

I would also use pprof and ensure your Go code is not leaking memory. There are multiple tutorials on using memory profilers to detect memory leaks. > On Mar 16, 2020, at 9:12 AM, Robert Engels wrote: > >  > Looks like pattern_db is a global. Are you sure you don’t have multiple Go >

Re: [go-nuts] Mem-Leak in Go method

Looks like pattern_db is a global. Are you sure you don’t have multiple Go routines calling the load? The global changes may not be visible- so the free is doing nothing. You probably need synchronization or pinning the access routine to a thread. > On Mar 16, 2020, at 9:03 AM, Nitish Saboo

Re: [go-nuts] Re: Mem-Leak in Go method

On Monday, 16 March 2020 14:25:52 UTC+1, Nitish Saboo wrote: > > Hi, > > I upgraded the go version and compiled the binary against go version 'go > version go1.12.4 linux/amd64'. > I ran the program for some time. I made almost 30-40 calls to the method > Load_Pattern_Db(). > The program starts

Re: [go-nuts] Mem-Leak in Go method

Hi, >From reading the code, I assume that the `pattern_db_new()` does some sort of allocation of a new pattern DB. I don't see any code releasing the pattern DB. Is that just missing from your post or something that some automatic mechanism does? >>Apologies, that part got missed in the code

Re: [go-nuts] Mem-Leak in Go method

This might be a dumb question but... From reading the code, I assume that the `pattern_db_new()` does some sort of allocation of a new pattern DB. I don't see any code releasing the pattern DB. Is that just missing from your post or something that some automatic mechanism does? If not, that

Re: [go-nuts] Re: Mem-Leak in Go method

Sounds like it. Probably in the C code. You need to check that your release/free code is correct. You can try a similar C program that instantiates and frees the structure to check for similar behavior. > On Mar 16, 2020, at 8:25 AM, Nitish Saboo wrote: > >  > Hi, > > I upgraded the go

Re: [go-nuts] Re: Mem-Leak in Go method

Hi, I upgraded the go version and compiled the binary against go version 'go version go1.12.4 linux/amd64'. I ran the program for some time. I made almost 30-40 calls to the method Load_Pattern_Db(). The program starts with 6% Mem Usage. The memory usage increases only when I call