On Sun, Nov 21, 2010 at 7:32 AM, Martin Sustrik <[email protected]> wrote: > On 11/21/2010 03:56 PM, Dhammika Pathirana wrote: > >> if (!plugged) is dereferencing this->plugged, but we've deleted this >> object (engine). >> So it's going to access deleted memory. > > Right. > >> Different option is to move engine deletion to a proxy object or to a >> static method. > > Or bubble up the "I am deleted" flag via a return value... > > Actually, there are several places like this in 0MQ codebase. I guess the > only real solution would be to make the whole thing event-driven. > > Right now individual objects communicate via events > (send_command/process_command) while the internal state machine of each > object is implemented using standard function calls. > > So, for example, when engine decides it wants to deallocate itself it can > trigger a "delete" event on itself and finish what it does decently. Later > on, when "delete" event is processed, the engine will be physically > deallocated. > > That way we can decouple individual actions of the state machine instead of > having them mingled as is the case now. >
I'm not sure, does this resolve the race condition? Engine is not attached to a poller, how do we notify events? Dhammika _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
