Wireshark · Wireshark-dev: Re: [Wireshark-dev] RFD: The Future of Memory Management in Wireshark

[Evan Huus <eapache@xxxxxxxxx>]

On Thu, Oct 25, 2012 at 4:00 PM, Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> wrote:
> Evan Huus wrote:
>>
>> On Thu, Oct 25, 2012 at 2:05 PM, Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
>> 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?