[zeromq-dev] About gracefully shutdown of own_t object

Martin Sustrik sustrik at 250bpm.com
Wed Oct 26 10:32:31 CEST 2011


Hi Raocheng,

> 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 ?

I don't think so.

There are other mechanisms that (should) guarantee that the shutdown of 
the object doesn't happen while some other object still has a pointer to it.

The seqnum mechanism is meant only to process any *pending* commands, 
that were issued before the shutdown sequence was started.

Does that help?
Martin



More information about the zeromq-dev mailing list