On Thu, Oct 25, 2012 at 4:00 PM, Jeff Morriss <jeff.morriss...@gmail.com> wrote: > Evan Huus wrote: >> >> On Thu, Oct 25, 2012 at 2:05 PM, Jeff Morriss <jeff.morriss...@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? ___________________________________________________________________________ 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-requ...@wireshark.org?subject=unsubscribe
