Wireshark-dev: Re: [Wireshark-dev] RFD: The Future of Memory Management in Wireshark
Le 25/10/2012 22:10, Evan Huus a écrit :
> 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?
+1 for me.
Regards,
Pascal.
