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).