[zeromq-dev] ØMQ VSM data alignment

[Andrew Hume]

indeed, this is an old trick. (the actual trick is making the first  
word after the buffer
be some marker like 0xdeadbeef and verifying it befor e using the  
structure.)

the other problem not mentioned here is that of different alignments.
for example, using direct i/o on SGIs required page-alignment of  
buffers.
in this case, i can force alignment of my buffer before i give it to  
zeromq,
but what makes the receiver do so?

maybe this doesn't matter overall, or is asking too much of zeromq.
or maybe there could be a plugin to force alignment?

martin, has this issue ever come up with your customers?

andrew

On Aug 5, 2010, at 6:30 AM, Matt Weinstein wrote:

> A nice side effect - if you overwrite the end of the VSM you'll  
> know PDQ
>
>
>
> On Aug 5, 2010, at 6:08 AM, Martin Sustrik <sustrik at 250bpm.com> wrote:
>
>> Matt Weinstein wrote:
>>
>>> Yes, but I want to do this:
>>>
>>> zmq::message_t foo;
>>>
>>> s.recv(&foo);
>>> my_struct const* pstruct = reinterpret_cast<my_struct const*> 
>>> (foo.data());
>>>
>>> cout << "Works like magic: " << pstruct->member << ". All your  
>>> processor
>>> are belong to Intel! (*)" << endl;
>>>
>>> That's the no-copy approach :-)
>>>
>>> I can do it with malloc() without issue or penalty...
>>
>> Fair enough. Thus kind of stuff would break on RISC architectures  
>> such
>> as SPARC.
>>
>> What about having VSM buffer as the first member of zmq_msg_t?
>>
>> Martin
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

------------------
Andrew Hume  (best -> Telework) +1 732-886-1886
andrew at research.att.com  (Work) +1 973-360-8651
AT&T Labs - Research; member of USENIX and LOPSA



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100805/af717a4c/attachment.htm>