Can you describe your performance needs in more detail? I missed the need for the struct values in the copy (obviously needed to encode to JSON). Going back to locks for a moment, my thought now is that a sync.RWMutex on this map would have an RLock taken by every struct read/write and then the Lock would be taken for the map copy which would return a map to copied structs instead of a map to pointers. Wouldn’t a fork lock the entire process while a larger copy happens anyway?
Where I’d start otherwise is adding additional data. Perhaps a second map could help with performance here. Matt On Monday, January 29, 2018 at 6:44:17 AM UTC-6, Julien Semaan wrote: > > 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 to have something similar to the fork behavior where I > could be working with a memory copy of the process in order to be able to > persist everything without holding a single lock either on the map or on > the actual structure. > > - Julien > > On Friday, 26 January 2018 15:44:46 UTC-5, Julien Semaan wrote: >> >> 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 access to it during the JSON encoding. >> I want to avoid that locking or have it held for the smallest amount of >> time. >> >> Next, my idea: >> Fork the process, leveraging the copy-on-write, JSON encode the good >> stuff, write it to a file, then exit the child process. >> During that time, I wouldn't need to lock-down access to the map since >> the forked process would have its own copy of the memory >> I pretty much wanted to do what Redis does, but in Golang, and for a >> multi-threaded process which I now learned is not really possible (please >> correct me if I'm wrong I'd be happy). >> >> So, with that failed idea behind me, I'm looking at how I could >> accomplish this in Golang while being memory efficient. >> >> I'm opened to a lot of ideas, but I'd consider myself intermediate in >> Golang and beginner in C (if the answer involves CGO) so I might need >> detailed examples if we get in deep low level stuff. >> >> I'd also like to have something that is pure Golang code since I'll be >> cross compiling this on multiple architectures using the go compiler. >> >> Obviously, if more details are needed to answer the question, I'd be >> happy to provide them. >> >> Thanks in advance! >> >> - Julien >> > -- 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://groups.google.com/d/optout.
