[go-nuts] Re: Async process state snapshotting in Golang

2018-01-30 Thread jul . semaan
As a follow-up, I managed to get everything to work as I wanted with forking but I got a major issue.. The golang runtime mutexes are invalidated by the forking, that means that anything in the runtime that needs a mutex is broken so garbage collection had to be disabled and additional memory a

[go-nuts] Re: Async process state snapshotting in Golang

2018-01-30 Thread jul . semaan
I believe copying the map containing structs and not pointers would make it consume twice the amount of memory which isn't desirable in my case. - Julien On Tuesday, 30 January 2018 00:09:21 UTC-5, Tamás Gulácsi wrote: > > Do you really need pointers tonyour structs in the map? Because that > c

[go-nuts] Re: Async process state snapshotting in Golang

2018-01-29 Thread jul . semaan
My main goal is to avoid complex granular locking inside the data structure since writes are very common in the map (whether its adding items or modifying the actual item). My idea was to implement MarshalJSON for my map and then while creating the JSON I'd be holding locks at the appropriate ti

[go-nuts] Re: Async process state snapshotting in Golang

2018-01-29 Thread jul . semaan
Hi, Thanks for all the input. Unfortunately, as Tamás and Jake pointed out, I can't simply grab a copy of the map that has the same pointers since I'll need to be locking the structure everytime I'm copying it. So that means Matt's idea wouldn't really work for my use-case I was really hoping

[go-nuts] Async process state snapshotting in Golang

2018-01-26 Thread jul . semaan
Hi, I'm currently tackling a head scratching problem (at least for me). First, I'll start by explaining my main goal: I have an in memory 'map[string]*SomeStructPointer' that I want to JSON encode and write to a file. Now since I want to prevent concurrent access to the map, I need to lock-down

[go-nuts] Re: Migrating from a classic OO pattern

2017-02-01 Thread jul . semaan
Thanks for the input. I'm in the process of doing our homework for migrating to golang so we appreciate all that input to be able to avoid common misuse of the language. I'm far from having perfect understanding on the language but I'm starting to get the differences with a «typical» OO language

[go-nuts] Re: Migrating from a classic OO pattern

2017-01-31 Thread jul . semaan
Hi Wanton, Thanks for the adjustment. Henry's solution which you've ++ed seems a bit «javascript-ish» and (IMO) a bit more prone to errors with scoping. On Monday, 30 January 2017 11:01:15 UTC-5, jul.s...@gmail.com wrote: > > Hi, > > Where I work, we are currently experimenting with golang in or

[go-nuts] Re: Migrating from a classic OO pattern

2017-01-31 Thread jul . semaan
Hi, First, thanks for your ideas. One downside with Henry's idea is that the attack function cannot access potential struct attributes of the Pitbull or Dog struct (I believe, correct me if I'm wrong). Although there weren't in my example, our code will certainly have struct attributes that nee

[go-nuts] Migrating from a classic OO pattern

2017-01-30 Thread jul . semaan
Hi, Where I work, we are currently experimenting with golang in order to migrate our existing Perl codebase to golang. Although Perl isn't a pure OO language, it allows for a lot of the OO patterns to be used. One of the patterns we do use is where a superclass method wraps a series of call to