Hi, thank you very much for your answer. Probably I can create and reset an arena object per request , but in this case (in my understanding) I don't see much gain vs a heap allocation. Also from memory fragmentation I don't see a big difference.
My first implementation used std::unique_ptr (to be sure to de-allocate the memory). When a message is receive it is passed around: each piece of SW grabs what it needs and at the end the memory is released. I though "arena" is meant as a sort of global "pot" reducing the " memory fragmentation" issue. Kind regards Il giorno lunedì 4 dicembre 2017 18:58:43 UTC+1, Adam Cozzette ha scritto: > > The most common idiom is that you have a server that just creates one > arena per request. When the request comes in, it creates an arena and uses > that throughout the processing of the request, and then destroys it once it > is done with that request. I think re-using a single Arena in multiple > long-lived threads is more unusual. In your case, is there any way to > structure things so that there is a clearly delineated request lifetime > that matches the arena lifetime? > > On Sat, Dec 2, 2017 at 11:55 PM, kino <[email protected] <javascript:>> > wrote: > >> Hi all, >> >> I am using proto.buf (C++) with Arena (its my first time). >> >> I have two linux processes (multi threaded) exchanging different types of >> msgs (proprietary protocols in an embedded environment) >> >> When I print the arena used Space I can see the memory size increasing >> (obliviously). >> >> One process could retrieve space after it has “consumed” the last >> incoming message but as far as I understood the only way it is to call the >> Reset() method on Arena obj forcing me to synchronize the threads with the >> process. >> >> Does exist a different idiom to re-claim memory avoiding the thread >> synchronization? >> >> Has arena a sort of automatic “garbage collector”? >> >> In the scenario above what do you suggest in order to keep the memory >> consumed by proto.buf under control ? >> >> Thanks in advance. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Protocol Buffers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/protobuf. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/protobuf. For more options, visit https://groups.google.com/d/optout.
