----- Original Message ----- > On Thu, Sep 20, 2012 at 12:32 PM, William Henry <whe...@redhat.com> > wrote: > > > > > > > ----- Original Message ----- > > > How about: > > > > > > int pn_messenger_subscribe(pn_messenger_t *messenger, const char > > > *source, > > > void* context); > > > > This one I like. It makes a lot of sense. > > > > > void *pn_message_subscribe_context(pn_message_t *msg); > > > > > > > This one less so. I have to make an extra call after I receive the > > message. Then the implementation needs to do some sort of lookup. > > I think > > it would be much more efficient if I had an API that returned the > > message > > and the context. > > > > I can't imagine there would be a significant difference in efficiency > in > any real world scenario. The internal mechanism to find the context > should > be exactly the same either way, and setting the context in an out > parameter > vs setting a slot on the message are both just pointer indirection.
I didn't realize you were setting something in the message. So you would modify the message? That's ok? If it is then I'm good with that. My thinking was: you'd have the context when you received the message. You'd have to look it up the other way. But if you set something when you receive it then is't more or less the same thing as what I was looking for. William > The > only difference would be the procedure call overhead associated with > actually accessing the pointer stored inside the message, and if that > starts being an issue then I think (a) we have much bigger trouble > since > that's how all the fields inside a message are accessed, and (b) > we're > totally awesome because we must have done an impossibly great job of > optimizing the rest of the code for this to even show up on a > profile. ;-) > > --Rafael >
