Wireshark mailing list archives
Re: Motivation for wmem [was: rev 52264]
From: Evan Huus <eapache () gmail com>
Date: Sun, 29 Sep 2013 19:53:33 -0400
On Sun, Sep 29, 2013 at 6:38 PM, Jakub Zawadzki <darkjames-ws () 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-ws () 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-request () wireshark org?subject=unsubscribe
Current thread:
- Motivation for wmem [was: rev 52264] Evan Huus (Sep 29)
- Re: Motivation for wmem [was: rev 52264] Jakub Zawadzki (Sep 29)
- Re: Motivation for wmem [was: rev 52264] Evan Huus (Sep 29)
- Re: Motivation for wmem [was: rev 52264] Bálint Réczey (Sep 30)
- Re: Motivation for wmem [was: rev 52264] Evan Huus (Sep 29)
- Re: Motivation for wmem [was: rev 52264] Jakub Zawadzki (Sep 29)