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