Notifying during object destruction is a dubious "feature": objects might end up recreating a bunch of state just before clearing it; language bindings might get spurious notifications during garbage collection runs. We freeze the notification queue before running the dispose() chain; if the object was temporarily vivified during dispose, we thaw the notification queue, otherwise we let the instance clear it when we finalize it. See: https://gitlab.gnome.org/GNOME/gjs/-/issues/445
Replace old `g_newa()` and `memset()` with `g_newa0()`
We now guarantee that GObjects will always be allocated at least as aligned as the basic types. If you want to put an element in your GObject which has higher alignment requirements, we can’t guarantee it will be aligned*. If you need it to be aligned, you’ll need to put it on the heap (aligned appropriately), or add appropriate padding in your GObject struct. *Actually, GSlice will guarantee that the whole GObject is aligned to at least the power of 2 greater than or equal to the size of the GObject, which means any element in the GObject struct should always be appropriate aligned if the compiler pads it appropriately. If malloc() is used, however, it doesn’t make that guarantee, so we can’t make that guarantee overall. Signed-off-by: Philip Withnall <withnall@endlessm.com> Helps: #1231
See the reasoning in the patch for why we believe GObjects *are* (already) as aligned as the basic types. We want to make this guarantee so that it’s guaranteed to be safe for people to ignore -Wcast-align warnings for GObjects which contain basic types. This typically happens with gdouble on 32-bit ARM platforms. The checks are slightly complicated by the need to support GObjects with custom constructors. We should expect that a custom construction function will chain up to g_object_constructor (which calls g_type_create_instance() as normal), but it’s possible that someone has done something crazy and uses a custom allocator which doesn’t return with the same alignment as GSlice. Hand them a warning in that case. If that is true, the code which uses their custom-constructed GObject can presumably already deal with the alignment it gets given. Signed-off-by: Philip Withnall <withnall@endlessm.com> Helps: #1231
gobject: Clarify behaviour of adding weak refs during disposal See merge request GNOME/glib!2255
Add a (diagnostic) warning for finalized floating objects Closes #2489 See merge request GNOME/glib!2247
When an object with toggle reference is notifying a change we just assume that this is true because of previous checks. However, while locking, another thread may have removed the toggle reference causing the waiting thread to abort (as no handler is set at that point). To avoid this, once we've got the toggle references mutex lock, check again if the object has toggle reference, and if it's not the case anymore just ignore the request. Add a test that triggers this, it's not 100% happening because this is of course timing related, but this is very close to the truth. Fixes: #2394
Small optimization for g_object_set See merge request GNOME/glib!2254
The previous wording was not clear about what happens if a new weak ref is taken during disposal (shortly after resurrecting the object with a new strong ref, otherwise taking the weak ref is invalid). See: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2064/diffs#note_1270092 Signed-off-by: Philip Withnall <pwithnall@endlessos.org> Helps: #2390
No need to call memset in the loop, we can just initialize all the values in one go. GtkBuilder is now using g_object_setv, so this may improve application start times a bit.