Wireshark mailing list archives
Re: RFD: The Future of Memory Management in Wireshark
From: Evan Huus <eapache () gmail com>
Date: Thu, 25 Oct 2012 14:20:54 -0400
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. Evan ___________________________________________________________________________ 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
Current thread:
- Re: RFD: The Future of Memory Management in Wireshark, (continued)
- Re: RFD: The Future of Memory Management in Wireshark Sébastien Tandel (Oct 24)
- Re: RFD: The Future of Memory Management in Wireshark Evan Huus (Oct 24)
- Re: RFD: The Future of Memory Management in Wireshark Sébastien Tandel (Oct 26)
- Re: RFD: The Future of Memory Management in Wireshark Evan Huus (Oct 26)
- Re: RFD: The Future of Memory Management in Wireshark Graham Bloice (Oct 26)
- Re: RFD: The Future of Memory Management in Wireshark Evan Huus (Oct 26)
- Re: RFD: The Future of Memory Management in Wireshark Sébastien Tandel (Oct 26)
- Re: RFD: The Future of Memory Management in Wireshark Evan Huus (Oct 26)
- Re: RFD: The Future of Memory Management in Wireshark Sébastien Tandel (Oct 26)
- Re: RFD: The Future of Memory Management in Wireshark Sébastien Tandel (Oct 24)
- Re: RFD: The Future of Memory Management in Wireshark Evan Huus (Oct 25)
- Re: RFD: The Future of Memory Management in Wireshark Jeff Morriss (Oct 25)
- Re: RFD: The Future of Memory Management in Wireshark Evan Huus (Oct 25)
- Re: RFD: The Future of Memory Management in Wireshark Pascal Quantin (Oct 25)
- Re: RFD: The Future of Memory Management in Wireshark Dirk Jagdmann (Oct 27)
- Re: RFD: The Future of Memory Management in Wireshark Evan Huus (Oct 27)
- Re: RFD: The Future of Memory Management in Wireshark Evan Huus (Oct 28)
- Re: RFD: The Future of Memory Management in Wireshark Jakub Zawadzki (Oct 28)
- Re: RFD: The Future of Memory Management in Wireshark Evan Huus (Oct 28)
- Re: RFD: The Future of Memory Management in Wireshark Jakub Zawadzki (Oct 29)
- Re: RFD: The Future of Memory Management in Wireshark Evan Huus (Oct 29)