[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