mercury icon indicating copy to clipboard operation
mercury copied to clipboard

hg_proc size pass

Open JohnPJenkins opened this issue 8 years ago • 1 comments

Was thinking about the proc issues talked about in #79 and had the following idea:

  • have a new type of proc operation - HG_GET_SIZE, which increments two (new) size values in the proc data structure - the type's size and, if applicable, the variable-length size of any (containing) bulk handles. The var-length is expected to be attached to a bulk handle
  • repurpose the proc workflow to:
    • call proc on the input type(s) with HG_GET_SIZE
    • determine whether to use eager mode or not (the size counters provide the necessary info)
    • allocate needed data
    • call proc again with HG_ENCODE

(the decode path would just need to track whether eager mode was used and otherwise be unchanged I think...)

There's a few benefits to this:

  • no need to repeatedly check buffer sizes and do reallocation and such. You have exactly one alloc
  • the HG_GET_SIZE implementation for most types we're interested in (C structs with some light variable-length data) is trivial.
  • eager mode issues are resolved for arbitrary types

Is this a reasonable approach?

JohnPJenkins avatar Apr 11 '16 21:04 JohnPJenkins

Sorry for not responding earlier, that's interesting I like the idea. Although that's still 2 passes :) Yes the proc component needs to be improved to get rid of the if size etc as much as we can I think.

soumagne avatar Apr 12 '16 18:04 soumagne