[zeromq-dev] About gracefully shutdown of own_t object

[raocheng]

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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20111024/bf37aefd/attachment.htm>