By http://www.zeromq.org/whitepapers:architecture: However, for couple of commands (basically for those that are sent across the object tree rather than along its latices) the guarantee doesn't apply. For these commands the sender calls inc_seqnum function on the destination object, which synchronously increments a counter stored in the destination object (sent_seqnum) before sending the command itself. When the destination object processes the command, it increases another counter (processed_seqnum). When the object is shutting down, it knows that it can't finish while processed_seqnum is less than sent_seqnum, i.e. there are still commands in flight to be delivered to this object.
But I think that there is still possibility of shutting down an object while a command for this object is still in flight: Suppose the sender and the receiver belongs to two different threads and: 1) At T1, processed_seqnum is equal to send_seqnum, then the receiving thread decides to destroy it (but then the CPU is interrupted and the action is deferred). 2) At T2, the sending thread prepares to send a command to the object and then increases its send_seqnum (Now processed_seqnum is less than sent_seqnum). 3) At T3, the receiving thread really destroys the object 4) At T4, the command is sent and put on the message queue. This is a command in flight whose target has been destroyed. Can this really happen ? Thanks!
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
