On Fri, Apr 6, 2018 at 9:05 PM, Justin Ross (JIRA) <j...@apache.org> wrote:
> > [ https://issues.apache.org/jira/browse/PROTON-1823?page= > com.atlassian.jira.plugin.system.issuetabpanels:comment- > tabpanel&focusedCommentId=16429180#comment-16429180 ] > > Justin Ross commented on PROTON-1823: > ------------------------------------- > > This is really nice! > > > [c] make it easier to send a message > > ------------------------------------ > > > > Key: PROTON-1823 > > URL: https://issues.apache.org/jira/browse/PROTON-1823 > > Project: Qpid Proton > > Issue Type: Improvement > > Components: proton-c > > Affects Versions: proton-c-0.22.0 > > Reporter: Alan Conway > > Assignee: Alan Conway > > Priority: Minor > > Fix For: proton-c-0.23.0 > > > > > > Encapsulates the awkward allocate-encode-expand dance required by > pn_message_encode() > > Supports the following 2 scenarios: > > 1. Simple: don't care about allocations, just send `pn_message_t *msg` > and forget it: > > pn_message_send(msg, sender, NULL) > > 2. Efficient: re-use a buffer, buffer is allocated and expanded as > required: > > pn_rwbytes_t buffer=\{0}; // Zero initialize, libary will do the > allocation > > ... > > pn_message_send(msg, sender, &buffer); // Expand as needed > > pn_message_send(msg2, sender2, &buffer); // etc. > > ... > > free(buffer->start); // Application must do final free of > buffer > > > Since you like that here's another thought - add a public API for just the "encode" part of pn_message_send() but allow the user to specify the realloc function. This covers two slightly more complicated cases with one extra API function, the implementation is already written in pn_message_send: 1. encode a message but don't send it immediately (e.g. because I have my own in-memory message queues and don't want to hold up the proton IO thread with the encoding work - which is among the most CPU intensive things proton does) pn_message_encode_realloc(msg, &mybuf, realloc); /* standard realloc */ pn_link_send(sender, mybuf.start, mybuf.size); /*later*/ 2. User your own allocator pn_message_encode_realloc(msg, &mybuf, &my_realloc_fn); Originally I thought about adding a 'realloc' parameter to pn_message_send itself, but that makes the simple cases less simple. By adding a separate function that encodes, but doesn't send, we keep those cases simple but kill 2 other birds with one stone (encoding outside the proton thread and using your own allocator.) Of course all this can be done directly by the user with the existing pn_message_encode(), but it's about 25 error-prone lines so maybe worth simplifying for something so common.
