mercury
mercury copied to clipboard
HG_Get_input_extra_buf giving back size = 0
I'm not sure if this is a bug or a misunderstanding on my part of what HG_Get_input_extra_buf
does (the same behavior happens with HG_Get_ouput_extra_buf
), but I can't seem to be able to allocate extra buffer space with those functions.
I am trying to bypass Mercury's serialization procedure by (1) registering the RPCs with NULL proc functions, (2) populating the handle's input buffer myself using HG_Get_input_buf
(on client) and HG_Get_ouput_buf
(on servers), (3) call HG_Get_input_extra_buf
/HG_Get_ouput_extra_buf
if the size returned by the HG_Get_input_buf
/HG_Get_output_buf
is not enought.
When the data fits in the eager buffer, the first difficulty I encountered is that Mercury is zero-ing these buffers prior to sending them, unless I use HG_Class_set_input_offset
and HG_Class_set_output_offset
to specify that I want a certain size to be used manually. The workaround I found was to call HG_Class_set_input_offset
with the result of HG_Class_get_input_eager_size
to tell Mercury I'm going to manually use the entire eager buffer.
When the data does not fit in the eager buffer, however, I have to call HG_Get_input_extra_buf
, but this function always gives me a buffer size of 0. I tried using HG_Class_set_input_offset
with a value larger than the eager buffer size, but it doesn't work, I still get 0.
Ideally, the behavior I would like to see is this:
- Mercury does not zero the part of the eager buffer that is after the offset set by the user (as said above, I have a workaround, so it's not a priority)
- The size argument of
HG_Get_input_extra_buf
/HG_Get_ouput_extra_buf
should be an input argument, not an output argument, specifying the extra size I want to allocate.
HG_Get_input_extra_buf()
will currently never "allocate" on its own, it will just return you a pointer to the extra payload buffer if there is one (on the receiving end). So currently that's right the get_extra_buf calls won't do what you are trying to do and you'd have to use hg_proc_save_ptr
which is not really ideal I recognize that. So ok I will look to see if I can fix the behavior of those two calls.
Also I'm very surprised by that statement: "Mercury is zero-ing these buffers prior to sending them". We never memset any buffers to 0, we just re-use buffers as they are, so I'm not sure where that 0 comes from ?
Also the set_offset calls are here for you to define a custom header, that header size must fit in the eager message size, you should get an error if it's larger.
I don't know if Mercury is zeroing the buffer beyond the set offset before sending or when receiving, but here is an example of what happens:
- client sets the input offset to 16 bytes, but puts data in the full buffer (in my case the eager input size is 4060)
- server sets the input offset to 128 bytes. When receiving a RPC from the client, the content of the buffer has 16 bytes worth of data, followed by only zeroes.
It's possible that the client is simply not sending the 4060 bytes, only the data up to the specified offset.