I am of the same opinion as Gordon that fixing the counting (to be atomic) will only address the current symptom without preventing other races that will present themselves later or on other hardware architectures.
Having two threads participating in Proton object reference counting is problematic as you can't guarantee which ones will end up running the finalizers (or resurectors if the reference count increases during finalization). The simplest way to ensure thread safety is to abstain from all direct (except for the handful of documented thread-safe interfaces) and indirect calls into the Proton engine from any non-callback thread. In C++ the latter is more difficult, as there can be hidden reference counting if you have Proton objects in your application objects. There you have be certain that you never have such objects being copied or destroyed in a non-callback thread. Alternatively, you can use dumb pointers to the Proton objects and use some application mechanism (mutex, condition variable...) to allow the non-callback thread to know when the pointer to the Proton object is valid. Cliff On Mon, Apr 22, 2019 at 1:49 AM Gordon Sim <g...@redhat.com> wrote: > On 19/04/2019 11:02 am, Rabih M wrote: > > We are only using proton objects in the handler, however, at destruction > > time, there is a race condition on the reference counter between the > proton > > objects from the main thread that are being destroyed, and the proton > > objects held by the proton thread. > > Can you elaborate a little on this? Access to (or destruction of) > objects from distinct connection should not need to be coordinated, > though objects for the same connection clearly have to be. > > Is the issue you are seeing related to some global state (e.g. sasl > destruction)? > > What calls are being made that are in a race? Is this plain C or c++ > with implicit calls being made by destructors? > > > The reference counter not being atomic is very error prone for users. > > How about transforming the int to an atomic int (already provided in C11 > > standard: https://en.cppreference.com/w/c/language/atomic)? > > My initial thought is that just making the counter atomic would not be > sufficient for general races, so it would be important to understand > what specific uses cases this was designed to protect. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
