Re: [PATCH 2/2] tcg: use QTree instead of GTree

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

On Sun, Jan 29, 2023 at 05:38:08PM -0500, Emilio Cota wrote:
> On Wed, Jan 25, 2023 at 15:58:25 +0000, Daniel P. Berrangé wrote:
> > On Wed, Jan 11, 2023 at 12:34:29PM +0000, Daniel P. Berrangé wrote:
> > > On Tue, Jan 10, 2023 at 10:55:36PM -0500, Emilio Cota wrote:
> > > > qemu-user can hang in a multi-threaded fork. One common
> > > > reason is that when creating a TB, between fork and exec
> > > > we manipulate a GTree whose memory allocator (GSlice) is
> > > > not fork-safe.
> > > 
> > > BTW, I just checked latest glib status
> > > 
> > >   https://gitlab.gnome.org/GNOME/glib/-/issues/1079
> > > 
> > > it appears they're pretty close to deciding to delete the
> > > GSlice impl and always use system malloc.
> > 
> > They have now merged the code to delete the GSlice custom allocator.
> > 
> > So glib >= 2.76.0 should not exhibit a hang
> > 
> > > So if we do take this patch series it'll hopefully be a time
> > > limited thing to carry. 
> > 
> > So the question is whether the issue is critical enough that we want
> > to carry a workaround for a while, vs telling users to upgrade to
> > newer glib  (once 2.76 actually gets released)
> 
> That is great news!
> 
> Since this is a correctness issue, I think we should ship with qtree
> and use it when configuring with glib <2.76.0. For later glib versions
> we would just use gtree, e.g. via typedef + inline functions.
> 
> Once the minimum glib required by the configure script is >= 2.76.0,
> then we'd remove qtree.
> 
> If that sounds like a good plan, I can send a v2.

I'm fine with it, but be good to have an opinion here from the TCG
subsystem maintainers, CC'ing them


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 :|