Each message has its own buffers; the size of the message is not relevant to that. As to processing messages without blocking, you should read the Guide and understand the principles of multithreaded applications.
The message size is not an issue (you can be busy with tiny messages too) unless the message does not fit into memory. Then you have to send it in fragments, and use some form of credit-based flow control to ensure the client does not get too much at a time. Again, see the Guide (credit-based flow control). -Pieter On Mon, Sep 9, 2013 at 12:50 PM, shancat <[email protected]> wrote: > I believe using a different context for different threads will solve the > over-writing problems but I think there's a bit more to consider. > > > On 9 September 2013 20:36, asif saeed <[email protected]> wrote: >> >> Hi, >> >> How do you propose to handle messages of size around 80MB when the >> application responsiveness is important? I mean the user should be able to >> process the next message while the current long message (>80MB size) should >> be off-loaded to another thread. However, will the content of the next >> message over-write any buffers allocated for the first long-message (>80MB)? >> How do you handle this scenario? >> >> Best regards, >> -Asif >> >> >> _______________________________________________ >> 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 > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
