[zeromq-dev] OOB abort of previously sent msgs?
sustrik at moloch.sk
Sat Aug 14 00:05:48 CEST 2010
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.
> On Aug 10, 2010, at 5:29 AM, Pieter Hintjens<ph at imatix.com> wrote:
>> On Tue, Aug 10, 2010 at 2:30 AM, Matt Weinstein<mattweinstein at 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.
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
More information about the zeromq-dev