[ https://issues.apache.org/jira/browse/PROTON-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13477199#comment-13477199 ]
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