Re: Motivation for wmem [was: rev 52264]

[Jakub Zawadzki <darkjames-ws () darkjames pl>]

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. 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? :-)

Eventually I might try to lobby replacing wmem_packet_scope() with some pinfo_current()->pool [or pinfo->pool if we 
have pinfo pointer]
- 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.

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
___________________________________________________________________________
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