On Sun, Sep 29, 2013 at 3:56 PM, Jakub Zawadzki
<darkjames-ws@xxxxxxxxxxxx> 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.
(In architectural terms, wmem makes the memory scope, allocator logic,
and data structures all orthogonal to each other.)
> 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!)
> Still I don't see any UI-wmem-pool, do we have one?
No, but it's trivial to create one *if* we can determine a sane scope
for it. I would love to be able to do this, I just haven't been able
to figure out how.
Cheers,
Evan
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...
