Martin Sustrik wrote: > Michael, > > >>> It's less trivial to implement (at very least it would require tweaking >>> the wire protocol), however, the added value is much greater than in the >>> simple iovec case. >>> >> Agreed, it certainly seems non-trivial, especially over some of the socket >> types. What did you have in mind for the API on the receiving side? Would >> the receiver have to know that it is receiving a message group, or would all >> of the messages be delivered as one large message? Or do you have another >> idea? >> > > I thought of leaving the receiving API as is: > > zmq_recv (&msg1); > zmq_recv (&msg2); > zmq_recv (&msg3); > > Note that as the messages are guaranteed to be delivered atomically in > one go, second and third recv won't ever block. > Additionally, it's possible to check for 'end of the group' flag: > > bool end = zmq_is_end_of_group (msg); > > However, my feeling is that such a functionality just makes the API more > complex without providing much added value. If needed, the same thing > can be done on application level. > > by which you mean a continuation_indicator would have to be in the app message and the api thread could loop creating zmq_msg and then calling zmq_recv?
jon > Martin > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
