GNOME's GLib Finally Has A Generic Reference Counting API

[phoronix]

Phoronix: GNOME's GLib Finally Has A Generic Reference Counting API

Fulfilling a 6+ year desire, GNOME's GLib library now has a generic memory reference counting API...

http://www.phoronix.com/scan.php?page=news_item&px=GLib-Generic-Ref-Count-API

[uid313]

I would love to see GLib, GObject Introspection and GTK+ support for .NET Core.

[kpedersen]

Hasn't GLib had this for a while? I.e (https://developer.gnome.org/gobject/...bject-weak-ref).

Or has it moved from GObject into the core GLib?

So long as this doesn't encourage the usage of GCC's unportable C RAII extension (__attribute__((cleanup(...)), I think it is good to have.

[cybertraveler]

Hasn't GLib had this for a while? I.e (https://developer.gnome.org/gobject/...bject-weak-ref).

Or has it moved from GObject into the core GLib?

So long as this doesn't encourage the usage of GCC's unportable C RAII extension (__attribute__((cleanup(...)), I think it is good to have.

That's only for GObjects. GLib exposes lots of non-GObject types:

https://developer.gnome.org/glib/stable/glib-Basic-Types.html

I'm pretty sure that this reference counting API is for all the non-GObject types that GLib exposes.

[carewolf]

What's the point when you still have to do it all manually because you using C, and do not have good portable RAII mechanisms? Wouldn't be basically just be an atomic and a pointer with some completely trivial functions or macros?

[cybertraveler]

What's the point when you still have to do it all manually because you using C, and do not have good portable RAII mechanisms? Wouldn't be basically just be an atomic and a pointer with some completely trivial functions or macros?

The point is that you wouldn't have to think about memory management so much. Just allocate your memory and let the special reference counting pointers work out when it can be freed.

[carewolf]

The point is that you wouldn't have to think about memory management so much. Just allocate your memory and let the special reference counting pointers work out when it can be freed.

But you would still have to manually reference and dereference it everywhere, so you would be thinking about it, and adding code to handle it everywhere. It is useful in C++ because it can be made automatic so you never have to deal with it, but that requires classes, constructor, destructors and overloads.

[Candy]

But you would still have to manually reference and dereference it everywhere, so you would be thinking about it, and adding code to handle it everywhere. It is useful in C++ because it can be made automatic so you never have to deal with it, but that requires classes, constructor, destructors and overloads.

They adopt the way Gnome-Shell is dealing with that situation. Allocate everything and free nothing

[cybertraveler]

But you would still have to manually reference and dereference it everywhere, so you would be thinking about it, and adding code to handle it everywhere.

True, so it doesn't save you from that work. But it does make memory management easier in some cases.

Imagine you load some data into memory and then you point to it from a whole bunch of struct objects which are used all over your program. With this new reference counting code you don't need to worry about when all of those objects are finished using that data in memory. This could be particularly useful in multi-threaded code. If you're just dealing with a single thread, then it's more likely you'll know when all the objects are done with the data, because control will probably return to the function which originally loaded the data into memory and you can probably just free the memory there. But with multi-threaded code, you may not have a convenient and simple way of finding out when all the other threads using the data are done with it.

I just checked the commit that Michael linked and they've stated that these special reference counting pointers are thread safe:

## Thread safety

The reference counting operations on data allocated using g_atomic_rc_box_alloc(),
g_atomic_rc_box_new(), and g_atomic_rc_box_dup() are guaranteed to be atomic, and thus
can be safely be performed by different threads. It is important to note that
only the reference acquisition and release are atomic; changes to the content
of the data are your responsibility.

So it wont have the convenience that you'd have in C++ (like you said), but it's an improvement for C programmers.

[coder]

The point is that you wouldn't have to think about memory management so much. Just allocate your memory and let the special reference counting pointers work out when it can be freed.

No one who's actually used GObject would say this.


Refcounting in C tends to be a mess, due to the temptation of having functions which "consume" a refcount. These are meant to do the caller the favor of not having to decrement the refcount. GStreamer is littered with such examples. Either way, refcounting in C is easily as error-prone as exclusive ownership, unless you truly have a shared ownership situation (in which case, you basically end up cobbling together an ad hoc refcount of some sort). But most objects with truly shared ownership were already GObject-derived. So, I don't know how much this will really help.

The reason refcounting works so nicely in C++ is because the mechanics are handled for you. This frees you to focus on higher-level issues of scope, lifetime, ownership, and ensuring your datastructures are acyclic (or use weak refs, when they aren't).