Folks,
Here's a pattern I run into a lot:
-- connect to a bunch of server threads via a ZMQ_REQ
-- assemble some data and send a bunch of SNDMORE packets
-- discover an error late in the sequence
-- look for the abort switch (but can't find it)
The current solution is to build a chain of zmq msg
On Tue, Aug 10, 2010 at 2:30 AM, Matt Weinstein wrote:
> What I'd prefer is a zmq_abort(socket) that kills the most recent
> train of packets, as long as a SNDMORE == 0 packet has not been sent.
> These are likely to be sitting in a ypipe somewhere along the chain.
I suspect the frames are sent
I figure I'll just treasure packets in the device until I know so I don't have
to special case the code.
I haven't looked at the REQ code but figured the sender's ypipe didn't show
ready until the last packet of a train was received which would offer that
opportunity.
Otherwise an uncooperat
On 08/10/2010 03:13 PM, Matt Weinstein wrote:
> I figure I'll just treasure packets in the device until I know so I don't
> have to special case the code.
>
> I haven't looked at the REQ code but figured the sender's ypipe didn't show
> ready until the last packet of a train was received which wo
On Sat, Aug 14, 2010 at 12:05 AM, Martin Sustrik wrote:
> Yes. That's the case.
>
> Multi-part messages are just messages, nothing complex. They are
> assembled at the sender and sent in one atomic go.
Ah, Matt, sorry for getting this wrong. I was thinking about Martin's
comment that we needed
