GLib merge requestshttps://gitlab.gnome.org/GNOME/glib/-/merge_requests2024-03-06T11:07:27Zhttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/3858[th/gobject-notify-queue] rework locking in `GObject` around `GObjectNotifyQu...2024-03-06T11:07:27ZThomas Haller[th/gobject-notify-queue] rework locking in `GObject` around `GObjectNotifyQueue`Access to GData already takes a mutex.
Use `g_datalist_id_update_atomic()`, which takes a callback and allows to perform more complex operations while holding that lock.
That allows to drop `object_bit_lock (object, OPTIONAL_BIT_LOCK_N...Access to GData already takes a mutex.
Use `g_datalist_id_update_atomic()`, which takes a callback and allows to perform more complex operations while holding that lock.
That allows to drop `object_bit_lock (object, OPTIONAL_BIT_LOCK_NOTIFY)` for locking around `GObjectNotifyQueue`.
Also, don't use a `GSList` but reallocate/grow the `GObjectNotifyQueue` buffer.
---
This is the first part. The follow up is !3864 which reworks more uses of `object_bit_lock()`.2.82https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3832Draft: [th/weak-ref-lock] gobject: use per-object bit-lock instead of global ...2024-01-18T09:44:06ZThomas HallerDraft: [th/weak-ref-lock] gobject: use per-object bit-lock instead of global RWLock for GWeakRefReplace the global RWLock with a per-object locking.
There are 3 problems with this patch:
1) it requires to add an `optional_flags2` field, which (on 64 archs) grows the size of `GObject` by adding a `GObjectPrivate`.
1) `g_weak_ref...Replace the global RWLock with a per-object locking.
There are 3 problems with this patch:
1) it requires to add an `optional_flags2` field, which (on 64 archs) grows the size of `GObject` by adding a `GObjectPrivate`.
1) `g_weak_ref_set()` now must temporarily ref+unref the previously set object. This is a visible change in behavior, because this can emit new toggle notifications and an object might now be destroyed on another thread than before.
1) two unit tests still fail. I cannot understand why that is (help requested). This could be due to 2), although, if a program is bothered by 2), it seems to do something unsound.
Maybe we could get away without 2), if GObject would hold a ref-counted locker object. That would be a struct (of two `gint`, one for the ref-count and one for the bitlock). The downside of that is this effectively applies to every object (at latest during dispose) and keeping track of that pointer and the struct consumes even more memory. So I think this patch is better... if the unit tests can be fixed.https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2377Draft: gobject: Mute toggle ref notifications for transient ref/unref pairs2024-01-05T21:07:14ZDaniel van Vugtdaniel.van.vugt@canonical.comDraft: gobject: Mute toggle ref notifications for transient ref/unref pairsThe ref/unref that occur in `g_object_notify*` are very short lived and
have a net zero effect on the reference count of the object. So allowing
them to trigger toggle notifications was incurring excessive garbage
collection in GJS (gnom...The ref/unref that occur in `g_object_notify*` are very short lived and
have a net zero effect on the reference count of the object. So allowing
them to trigger toggle notifications was incurring excessive garbage
collection in GJS (gnome-shell).
Now we "mute" toggle notifications specifically for those brief references
in `g_object_notify*` so that notifications like the ticking of
`GnomeWallClock` don't indirectly lead to garbage collection runs.
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4800
Closes: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/20852.79.1Philip WithnallPhilip Withnallhttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/1741Draft: Fix alignment warnings of GObject on various platforms2023-12-04T15:35:44ZChristian HergertDraft: Fix alignment warnings of GObject on various platformsThis fixes #1231 on some platforms where Clang is used or architectures where the alignment requirements are different. In particular, it squashes a warning about increasing alignments from 1 to 8 when you have a GObject subclass with a ...This fixes #1231 on some platforms where Clang is used or architectures where the alignment requirements are different. In particular, it squashes a warning about increasing alignments from 1 to 8 when you have a GObject subclass with a `gdouble` immediately following the head struct.https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3570tests: set slow for gobject/{threadtests,dynamictests,performance}2023-10-04T10:22:23ZAcid Xeontests: set slow for gobject/{threadtests,dynamictests,performance}These tests takes the below time on a most powerful RISC-V hardware, which are longer than test_timeout:
351/353 glib:gobject / threadtests OK 61.93s 4 subtests passed
352/353 glib:gobject+performance+no-valgrind / performance OK 85.33...These tests takes the below time on a most powerful RISC-V hardware, which are longer than test_timeout:
351/353 glib:gobject / threadtests OK 61.93s 4 subtests passed
352/353 glib:gobject+performance+no-valgrind / performance OK 85.33s
353/353 glib:gobject / dynamictests OK 101.96s 2 subtests passed
Signed-off-by: Xeonacid h.dwwwwww@gmail.comhttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/2683Speed up object finalization more2023-07-09T18:03:18ZMatthias ClasenSpeed up object finalization moreDon't clean the GDataList 3 times. Twice is enough.Don't clean the GDataList 3 times. Twice is enough.Matthias ClasenMatthias Clasenhttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/2278Speed up object construction2023-07-09T18:03:18ZMatthias ClasenSpeed up object constructionThis branch has various changes to speed up the code in the property setting
and object construction codepath.This branch has various changes to speed up the code in the property setting
and object construction codepath.Matthias ClasenMatthias Clasenhttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/2695Move tests/gobject/performance.c and tests/gobject/performance-threaded.c to ...2023-07-09T18:03:18ZEmmanuel FleuryMove tests/gobject/performance.c and tests/gobject/performance-threaded.c to gobject/tests/*Helps issue #1434Helps issue #1434https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2676Reduce locking overhead for param specs2023-07-09T18:03:17ZMatthias ClasenReduce locking overhead for param specsOnly take the pspec pool mutex once per
g_object_new or g_object_set call.
This branch sits on top of gobject-speedups2Only take the pspec pool mutex once per
g_object_new or g_object_set call.
This branch sits on top of gobject-speedups2https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2757gobject: Export gobject_init() function when doing static compilation2022-11-28T12:11:14ZOlivier Crêtegobject: Export gobject_init() function when doing static compilationWhen statically compiling GObject and another GObject based library
into the same shared object, the constructors need to be called in the
right order.
This is the same as gobject_win32_init(), except that it's not
specific to Windows. ...When statically compiling GObject and another GObject based library
into the same shared object, the constructors need to be called in the
right order.
This is the same as gobject_win32_init(), except that it's not
specific to Windows. The same thing applies on other platforms.
My goal is to be able to link the glib-networking plugins into the same shared object as glib itself.https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1288WIP: Add a G_DECLARE macro for "protected" types2022-11-28T12:07:15ZEmmanuele BassiWIP: Add a G_DECLARE macro for "protected" typesCertain libraries want to provide types that are derivable for internal
users, but final for any external consumer of the API. Other languages
use the term "protected" to refer to this kind of type visibility
attribute.
Since we're prov...Certain libraries want to provide types that are derivable for internal
users, but final for any external consumer of the API. Other languages
use the term "protected" to refer to this kind of type visibility
attribute.
Since we're providing macros to declare derivable and final types, we
should also provide a macro for declaring protected types.
The mechanism is the same as the other G_DECLARE macros; protected
types:
- define an opaque type for the instance, like G_DEFINE_FINAL_TYPE
- define an opaque type for the class
- define cast and type check functions for instance pointers, for
public consumers, and cast and type check functions for class pointers,
for internal consumers
- omit an accessor for retrieving the class structure from the instance
structure, as it would be pointless to do sohttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/1558Allow instance/class private size bigger than 64k2022-07-07T10:59:57ZSebastian DrögeAllow instance/class private size bigger than 64kThere is no actual reason for it being limited to 64k. For the public
instance/class structs the 64k limit exists because of the limitations
of GTypeInfo but there is no such limitation here.
As in various places we sum up all the priva...There is no actual reason for it being limited to 64k. For the public
instance/class structs the 64k limit exists because of the limitations
of GTypeInfo but there is no such limitation here.
As in various places we sum up all the private struct sizes and still
require the sum to be smaller than 64k, it can relatively easily happen
that some type is hitting the limit. As this can also happen for example
when adding a private field to some base class, which then breaks a
subclass that happens to use just too much data now, this means adding
private fields can cause ABI breakage.Sebastian DrögeSebastian Drögehttps://gitlab.gnome.org/GNOME/glib/-/merge_requests/2718gobject: Add function to check if GWeakRef is empty without changing it2022-06-15T14:18:11ZMarco Trevisanmail@3v1n0.netgobject: Add function to check if GWeakRef is empty without changing itGWeakRef can hold a destroyed pointer but we don't have a way to check
if the weak reference is empty without affecting the wrapped object
references, and this may lead to cause the object to be re-referenced
when it's about to be destro...GWeakRef can hold a destroyed pointer but we don't have a way to check
if the weak reference is empty without affecting the wrapped object
references, and this may lead to cause the object to be re-referenced
when it's about to be destroyed, causing its toggle references to change
during observation.
So add a function that allows to only safely check for weak references
that contains an object that has been disposed, while when we return
FALSE we can't guarantee that the object is still alive.
This can be still a relevant information when monitoring objects through
weak references.
---
Ideally such function should never return real `FALSE` but instead an `UNDEFINED` value, but to do that we'd need to reverse the logic, and I'm not in love which such idea either.https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2410gtype: Define G_DECLARE_BOXED_TYPE macro2022-04-23T05:42:44ZLogan Rathbonegtype: Define G_DECLARE_BOXED_TYPE macroThis is for consistency with the other G_DECLARE_*_TYPE macros.
Developers that have never programmed with GObject since 2.44 may be
confused about how to actually write a GType declaration.
This macro may not buy as much as the G_DECL...This is for consistency with the other G_DECLARE_*_TYPE macros.
Developers that have never programmed with GObject since 2.44 may be
confused about how to actually write a GType declaration.
This macro may not buy as much as the G_DECLARE_*_TYPE macros, but
promotes code readability and brings creating boxed types more in line
with creating other GTypes in GObject-oriented header files.https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2430Draft: generic/parametrized types2022-03-09T14:17:35ZLorenz WildbergDraft: generic/parametrized typesTo add support for generic types to the type system, there can be now
additional information added to a type, which are specifying,
if a type has parameters.
TypeNode's have a new field "type_parameters" with a hashtable.
The keys in th...To add support for generic types to the type system, there can be now
additional information added to a type, which are specifying,
if a type has parameters.
TypeNode's have a new field "type_parameters" with a hashtable.
The keys in the hashtable are the names of the type parameters in strings.
And the values are containing the minimum type, that instances
of the generic type need to specify.
Whenever someone wants to instanciate such a type, there is a new type
registered in the background for the specific combination of parameter values.
These types are final and instantiable instead of abstract.
I called this hard-coding of the type parameter "implementing", and the type
parameters in the abstract generic types are "required", because they require
a type or from it derived types as the parameter. And these requirements are
then implemented by the other final types.
So now there is also information per parameter, about if it is "required" or
"implemented". The automatically created types turn all parameters into
"implemented" ones, with the type that they implement as the parameter value.
You can also have types with some parameters as "required" and some as
"implemented". This is useful, if a type derives from a generic type (which
copies all required and implemented parameters over), but implements only
a few parameters, or if it implements all parameters
and adds a new "required" one (which would make it again a generic type).
To make for example different "implementations" of the same generic type
"compatible", if the parameters are derived from each other,
there are also changes to g_type_is_a(). It checks now if the parents of both
types are derived from each other, and for each "generic" and "implemented"
parameter, if there is a corresponding "implemented" parameter,
that meets the requirements.
Because of that all parameters need to be kept in all derived types,
even if they are long before already "implemented". So you can use a parameter
name only once.
To get the type id of an "implementation" of a generic type, you can use
g_type_get_implemented_type (). This takes the generic type, and a list of
parameter name, value arguments and returns the resulting type id.
You can then use it for type checking or instantiating.
To create a new generic type, you can use g_type_add_required_type_parameter().
this just adds a required parameter to the type. The same is
g_type_implement_type_parameter() doing with implemented parameters.
This can be useful, when you "implement" parameters in a derived type,
but which isn't only a instance of the type.
Important here is only, that the implemented type must be "required"
in the parent type, and that it is not allowed to turn a "implemented" into
a "required" parameter again.
Everything else is up to the type. You can create gobject,
but also fundamental generic types. For gobject there are two useful
macros for G_DEFINE_TYPE_WITH_CODE(). I have also made two example classes
for demonstration.
This is completely experimental, and don't expect it to actually run.
I am also very unsure about the naming. You know probably better terms.
Other things I haven't looked at yet are ref/unref of type_data and bindings.https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2062Add G_PARAM_NONNULL2021-09-23T17:32:29ZMarc-André LureauAdd G_PARAM_NONNULLIntroduce a new flag to allow GObject get/set check for non-null pointer.Introduce a new flag to allow GObject get/set check for non-null pointer.https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2168Description: Raw pointers have to be freed manually2021-06-25T10:41:41ZDarkTrickDescription: Raw pointers have to be freed manually*Goal of this change*: Make it clear to the user, that non-GObjects pointers are not owned and memory has to handled manually.*Goal of this change*: Make it clear to the user, that non-GObjects pointers are not owned and memory has to handled manually.https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2093RFC: gtype: Introduce G_DECLARE_OPAQUE_TYPE()2021-05-10T10:16:44ZJonas ÅdahlRFC: gtype: Introduce G_DECLARE_OPAQUE_TYPE()This works like G_DECLARE_FINAL_TYPE() and G_DECLARE_DERIVABLE_TYPE()
except it expects both the instance struct and the class struct to be
defined manually in the C file.
The motivation for this is to expose a non-derivable type as API...This works like G_DECLARE_FINAL_TYPE() and G_DECLARE_DERIVABLE_TYPE()
except it expects both the instance struct and the class struct to be
defined manually in the C file.
The motivation for this is to expose a non-derivable type as API, but
without exposing the private type class details.
For example the following:
* A base class MyBase with a MyBaseClass declared using
G_DECLARE_DERIVABLE_TYPE(), with a MyBaseClass with private vfuncs.
* A class MyBaseFoo that inherits MyBase and implements the
MyBaseClass vfuncs.
* A my_base_foo_new() which constructs a MyBaseFoo instance.
With G_DECLARE_OPAQUE_TYPE() one can declare the MyBaseFoo in an
installed header file, without needing to expose MyBaseClass, which
would be needed if one would use G_DECLARE_FINAL_TYPE().
--------
Just some experiment I did; I want to avoid exposing the guts of the type class tree but expose sub types via.https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2057Update signal accumulator docs.2021-04-22T09:42:56ZJohn McCambridgeUpdate signal accumulator docs.Reflect that a FALSE returned from the accumulator will still emit signals with the flag G_SIGNAL_RUN_CLEANUP.Reflect that a FALSE returned from the accumulator will still emit signals with the flag G_SIGNAL_RUN_CLEANUP.https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1010gobject.h: Update documentation g_set_object2020-11-14T20:38:01ZДилян Палаузовgit-dpa@aegee.orggobject.h: Update documentation g_set_objectCloses: #1849Closes: #1849