Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [paho-dev] Payload buffer alignment in C/C++ clients

Hi Frank,

did you stumble over this issue?  I assume your thought didn't spring from thin air!  Or maybe it did...

It wouldn't be hard to make this arrangement.   If we are using malloc to allocate the payload area, which I think we are, then this might have some alignment guarantee, although this is dependent on C library and OS.  Gcc doc says:

"The address of a block returned by malloc or realloc in GNU systems is always a multiple of eight (or sixteen on 64-bit systems)"

I read the Linux man page for malloc first, which didn't say anything about alignment but did remind me of one of my favourite Linux man page quotes:

"By  default, Linux follows an optimistic memory allocation strategy.  This means that when malloc() returns non-NULL there is no  guarantee  that  the  memory  really  is available."

LOL - and I mean it.

Ian



On 01/23/2015 03:07 PM, Frank Pagliughi wrote:
Hey All,

Here's a strange one.  In the C/C+ clients, can we (or should we) make an alignment guarantee on the incoming payload buffers for an application?

I know that the payloads are supposed to just be binary byte blobs, so a byte alignment is all that is to be expected. But with a modest alignment guarantee, a subscriber can make use of the payload buffer directly rather than incurring a copy penalty on each incoming buffer.

For example, say that an app is publishing a native array of 32-bit int's:
int32_t arr[N];
...
MQTTClient_publish(cli, topicStr, (int) (N*sizeof(int32_t)), arr, ...);
Assuming that the receiver has verified that it is using the same byte ordering, it could do this:
int msg_arrvd(void *context, char *topicName, int topicLen, MQTTClient_message *msg)
{
    size_t i, n = msg->payloadlen / sizeof(int32_t)
    const int* arr = (const int*) msg->payload;

    for(i=0; i<n; ++i)
        do_something_with_int(*arr++);

    // ...
    return 1;
}
This will work on many platforms, including a PC, but if the incoming payload buffer does not have at least 4-byte alignment, it would cause a severe performance penalty, and some CPU's like an ARM will generate alignment faults.

So maybe the libraries could make some guarantee about alignment for the payload buffers? Aligned to the native word size? Or the native "long" size? Or to a 4, 8, 16, 256 byte boundary, etc?

Just a thought.

Thanks,
Frank


_______________________________________________
paho-dev mailing list
paho-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/paho-dev

-- 
Ian Craggs                          
icraggs@xxxxxxxxxx                 IBM United Kingdom
Paho Project Lead; Committer on Mosquitto


Back to the top