Rafael H. Schloming commented on PROTON-33:

There are a bigger set of API concerns that need to be investigated involving 
"zero" copy scenarios.
> Provide API for user managed pn_message_t payload/memory
> --------------------------------------------------------
>                 Key: PROTON-33
>                 URL: https://issues.apache.org/jira/browse/PROTON-33
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: proton-c
>            Reporter: William Henry
>              Labels: api
> Some users will have their own frameworks and methods of managing the data 
> received.
> Currently in the pn_message_t the only way to get at the payload/data is to 
> call pn_message_save with a pre-allocated buffer of data.  pn_message_save 
> copies to that data buffer and returns the actual size. (so for example if I 
> passed an allocated buffer of 1028 I might be returned 8 bytes).
> In many situations this alloc is expensive - especially when integrating with 
> established frameworks that already do the copy - now there are two allocs. 
> I suggest an API call that returns the message payload as a pointer.  There 
> is a risk that this might get deleted and a pn_message_t should check that 
> it's buffer is still valid (I assume it would.) In the case I'm looking at 
> the "other" framework is merely making it's own copy but doesn't free the 
> memory (but, as I said, there is a risk it could).
> I'm willing to debate pn_message_t having an API that returns a copy but I 
> imagine many users will any up complaining about the alloc in the that API 
> call.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to