Re: [PATCH] qobject: make refcount atomic

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Oct 08, 2025 at 05:27:01PM +0200, Paolo Bonzini wrote:
> The Rust bindings for QObject will only operate on complete objects,
> treating them as immutable as long as the Rust QObject is live.
> 
> With that constraint, it is trivial for Rust code to treat QObjects as
> thread-safe; all that's needed is to make reference count operations
> atomic.  Do the same when the C code adds or removes references, since
> we don't really know what the Rust code is up to; of course C code will
> have to agree with not making changes to the QObjects after they've
> been passed to Rust code.

I wonder whether that latter constraint on the C code will hold
true in practice ? Particularly thinking about scenarios where
we add/remove link properties to QObject's, potentially at any
time during life of QEMU via QMP/HMP commands ?

> 
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
>  include/qobject/qobject.h | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/include/qobject/qobject.h b/include/qobject/qobject.h
> index a6244d0ce00..02f4c6a6eb2 100644
> --- a/include/qobject/qobject.h
> +++ b/include/qobject/qobject.h
> @@ -32,6 +32,7 @@
>  #ifndef QOBJECT_H
>  #define QOBJECT_H
>  
> +#include "qemu/atomic.h"
>  #include "qapi/qapi-builtin-types.h"
>  
>  /* Not for use outside include/qobject/ */
> @@ -73,7 +74,7 @@ QEMU_BUILD_BUG_MSG(QTYPE__MAX != 7,
>  static inline void qobject_ref_impl(QObject *obj)
>  {
>      if (obj) {
> -        obj->base.refcnt++;
> +        qatomic_inc(&obj->base.refcnt);
>      }
>  }
>  
> @@ -95,7 +96,7 @@ void qobject_destroy(QObject *obj);
>  static inline void qobject_unref_impl(QObject *obj)
>  {
>      assert(!obj || obj->base.refcnt);
> -    if (obj && --obj->base.refcnt == 0) {
> +    if (obj && qatomic_fetch_dec(&obj->base.refcnt) == 1) {
>          qobject_destroy(obj);
>      }
>  }

With this unref method being void, how does the Rust code
know when a QObject is no longer alive after it has called
unref ? Does it need to know this to provide any safety
guarantees ?

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|