On Sun, Sep 29, 2013 at 6:38 PM, Jakub Zawadzki <darkjames...@darkjames.pl> wrote: > On Sun, Sep 29, 2013 at 05:35:59PM -0400, Evan Huus wrote: >> On Sun, Sep 29, 2013 at 3:56 PM, Jakub Zawadzki >> <darkjames...@darkjames.pl> wrote: >> > But back to topic (cause you'll probably see this problem few more times). >> > I don't quite get a point why we need to change everything to wmem. >> > (To be honest I still don't quite get why we need wmem_ at all, but let's >> > skip that). >> >> Wmem is mostly a replacement for emem, because emem was becoming >> impossible to maintain and reason about (recall, for example, bug >> #5284). If you could still deal with emem, congratulations, but the >> rest of us mortals needed something more comprehensible. > > Evan, I *really* don't see what wmem_ is fixing.
Then I must be doing an absolutely awful job of explaining. I apologize, I'm just not sure how else to approach it. > I mostly see that we have few > extra assertions to dissallow use it when not dissecting packets. > But if we want to remove totally ep_ we'd need to fix this shit anyway. > > I'm not fan of this, sorry. Right now wmem_ is quite long in our eco system, > so this talk is pointless. Please, just let's skip this discussion. > I'll make some comments from time to time (/me just being a little > conservative), > but I think you can life with it? :-) I wish we were all on the same page, I think that if we could come to a common understanding then things would go more smoothly. > Eventually I might try to lobby replacing wmem_packet_scope() with some > pinfo_current()->pool [or pinfo->pool if we have pinfo pointer] This is part of the plan I have for wmem, definitely. It's just not as high priority for now. > - that's all. > >> > But if we really want to do that (change everything to wmem_), we NEED >> > some ep-like temporary pool (which will work both for UI and dissection), >> > or some function which will return packet-pool or gui-pool if there's no >> > dissection. Otherwise we need to remove some functionality. >> >> No. This is one of the things I dislike most about emem. Using ep_ >> memory outside of packet dissection provides no guarantees at all as >> to when that memory is going to be freed, and makes it difficult if >> not impossible to reason about scope. The majority of such uses I >> expect to be converted to manually-managed memory. If there is some >> obvious common UI-scope then we can easily create a new pool for that >> memory, but the cases I have reviewed have not had any obvious common >> scope, they are simply using ep_ and assuming that it goes away at >> some point (and not while they still need it!) > > Ok, this can be fixed with g_free() after val_to_str_[dup|format]. > I'm fine with this. +1 from me. > >> P.S. I have a pleasant day-dream where libwireshark gets rewritten in >> a garbage-collected language like Go, but I somehow suspect that isn't >> going to happen... > > Why Go? if we talk about better languages I'd rather use D. > If we talk about glib-language-environment than Vala has reference couting. Because I already know Go :) It was just an idle thought, not a serious proposal. > Still there's popular GC for C: http://www.hpl.hp.com/personal/Hans_Boehm/gc/ > and there's alredy interested in using that: > http://www.wireshark.org/lists/wireshark-dev/201210/msg00229.html I have not looked closely, but I think it would be easy to cause memory leaks by embedding memory addresses in packet bytes. Maybe worth experimenting with though. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
