[zeromq-dev] Very Small Messages/Manual

Ben Kloosterman bklooste at gmail.com
Tue Jul 27 14:09:55 CEST 2010


>
 >>  >Agreed, but there's no way to set the MAX_VSM_SIZE at runtime.
 >Compiler
 >>  >has to be aware of it.
 >>
 >> True , but I bet changing it is not tested either  .
 >>
 >> This is more of an architecture decision  , instead of fixed size we
 >could
 >> just assume the message is flexible and get the pipe to allocate the
 >memory
 >> and just place the struct at the header. Instead of incrementing it by
 >a
 >> constant message size you bump up the counter by the size in the
 >message.
 >
 >Think of this:
 >
 >     zmq_msg_t msg;
 >     zmq_msg_init_size (&msg, 5);
 >     memcpy (zmq_msg_data (&msg), 5, "ABCDE");
 >     ...
 >
 >Here the _compiler_ allocates the storage for the data on the stack. The
 >size of the structure has to be fixed otherwise compiler won't know how
 >to adjust the stack pointer.

I don't dispute with current design it has to be like that ..but the memory
could be managed by the pipe which would allow variable messages..And for
this type of message  the pipe would return a pointer where the data would
need to be written to. 

zmq_msg_t* msg  = pipe->CreateNextMessage(size);
memcpy (zmq_msg_data (msg), 5, "ABCDE");

The current design allows the messages to be separate from the transport (
which is good) but the message size is effectively static. The one I
mentioned allows variable sized messages but they only exist in the context
of a transport and would need a message holder and a copy to exist outside
of it. The one I suggested also suffers from a call back to user land for
small messages  ( in return for a copy) but im not sure what will be best.


Anyway im playing around with it as an optional inproc pre allocated pipe
for a very limited use case  ( eg super fast in proc for multi core but
small messages) .  
Regards, 
Ben Kloosterman 





More information about the zeromq-dev mailing list