Re: RFD: The Future of Memory Management in Wireshark

[Pascal Quantin <pascal.quantin () gmail com>]

Le 25/10/2012 22:10, Evan Huus a écrit :
> On Thu, Oct 25, 2012 at 4:00 PM, Jeff Morriss <jeff.morriss.ws () gmail com> wrote:
> > Evan Huus wrote:
> > > On Thu, Oct 25, 2012 at 2:05 PM, Jeff Morriss <jeff.morriss.ws () gmail com>
> > > wrote:
> > > > Evan Huus wrote:
> > > > > The usage might look something like this:
> > > > >
> > > > > wmem_allocator_t *ep_scope = wmem_create_glib_allocator();
> > > > > doWork(ep_scope);
> > > > > wmem_destroy_glib_allocator(ep_scope);
> > > > >
> > > > > and then in doWork, instead of ep_alloc(numBytes) you would call
> > > > > wmem_alloc(ep_scope, numBytes).
> > > >
> > > > Hopefully stupid question (without having had time to look at the code):
> > > > does that mean passing ep_scope all the way down to the dissectors and
> > > > where
> > > > they do their allocations?
> > >
> > > Unfortunately, yes. You'd have an se_scope as well (and potentially
> > > others) so they'd probably be wrapped up in a single `scopes` object,
> > > but it does mean one more parameter to pass around.
> > >
> > > > I hope not; it's been a pain just to get pinfo
> > > > all the way down into some of the routines (for expert infos).
> > >
> > > I know, but I don't know that there's a nice way around it.
> > >
> > > On that thought: since the amount of packet-related data keeps
> > > growing, might it be worth the effort to wrap all the current
> > > parameters (tvbuff, pinfo, tree, etc.) into a single 'dissect-me'
> > > struct to pass around? I know it's not really good style in a lot of
> > > ways, but it would make it a lot easier to expose new things to
> > > dissectors and automatically have them available in all of the
> > > internal functions.
> >
> > Oof.  Well, that's one advantage of the current system (that keeps the
> > allocators in emem.c and has lots of little wrapper functions).
> >
> > For pinfo I had also contemplated a function to retrieve the current pinfo,
> > with the thought that this function would have to get smarter if/when
> > multiple threads are supported.
> >
> > A "dissect-me" blob honestly doesn't sound too bad at the moment though...
> > Quite a number of dissector functions have a _lot_ of arguments (usually
> > including tvb, tree, and, if we're lucky ;-), pinfo).
> General thoughts from the list on whether or not this would be a good idea?

+1 for me.

Regards,
Pascal.

___________________________________________________________________________
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