Dhammika,
I donno, may be we should simplify this. Why don't we add a refcount?
As a quick workaround -- yes. Do you have a patch for that kind of solution?However, thinking about it conceptually, the problem is more generic. Namely, object A can call object B which in turn calls object A. In such a scenario, the inner call on A works on inconsistent state as the outer call isn't yet completed. Other way round, outer call on A gets the state changed underneath its feet when it calls B (see seq1.png attached).
The real solution, IMO, would be to use events to sequence actions on individual objects. That way there won't be inner and outer call, rather, there will be two event handlers executed one after another (see seq2.png).
Brief code review of 0MQ shows that this kind of problem only happens within a cluster of object composed of session, engine and decoder/encoder. The rest of the system (sockets, pipes) is using events already and doesn't have to be changed.
Martin
<<attachment: seq1.png>>
<<attachment: seq2.png>>
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
