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 would offer that > opportunity. > > Otherwise an uncooperative writer could hang the device waiting for no MORE > bit. >
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. Martin > > > > > > > On Aug 10, 2010, at 5:29 AM, Pieter Hintjens<p...@imatix.com> wrote: > > >> On Tue, Aug 10, 2010 at 2:30 AM, Matt Weinstein<mattweinst...@gmail.com> >> 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 out as soon as possible. The atomic >> delivery is actually done by receivers. If you want the ability to >> abort a multipart message, you either need to build it in memory, as >> you're doing, or else add your own operational control on top. >> >> Here is a simple scheme: specify that the last frame in the request is >> an operation, either EXECUTE or CANCEL. Then to abort a job send a >> CANCEL frame with SNDMORE=0. >> >> -Pieter >> _______________________________________________ >> zeromq-dev mailing list >> zeromq-dev@lists.zeromq.org >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
