After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 590808 - GKeyFile should have a refcount and a boxed type in GObject
GKeyFile should have a refcount and a boxed type in GObject
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
: 301034 615070 652880 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-08-05 08:29 UTC by Colin Walters
Modified: 2011-10-15 21:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
[GKeyFile] Add g_key_file_copy and make it a boxed (2.76 KB, patch)
2010-04-07 15:09 UTC, Johan (not receiving bugmail) Dahlin
none Details | Review
[GKeyFile] Register a boxed type (1.04 KB, patch)
2010-04-07 16:20 UTC, Johan (not receiving bugmail) Dahlin
none Details | Review
[GKeyFile] Add refcounting API (4.37 KB, patch)
2010-04-08 19:09 UTC, Johan (not receiving bugmail) Dahlin
reviewed Details | Review
[GKeyFile] Register a boxed type (1.04 KB, patch)
2010-04-08 19:09 UTC, Johan (not receiving bugmail) Dahlin
reviewed Details | Review
[GKeyFile] Register a boxed type (1.20 KB, patch)
2010-04-10 11:55 UTC, Johan (not receiving bugmail) Dahlin
needs-work Details | Review
GKeyFile: Add refcounting API (4.35 KB, patch)
2011-06-22 16:23 UTC, Giovanni Campagna
reviewed Details | Review
glib: turn GKeyFile into a boxed for introspection (2.28 KB, patch)
2011-06-22 16:32 UTC, Giovanni Campagna
reviewed Details | Review
GKeyFile: improve introspection annotations (10.77 KB, patch)
2011-06-22 16:32 UTC, Giovanni Campagna
accepted-commit_now Details | Review

Description Colin Walters 2009-08-05 08:29:08 UTC
This would make it more usable directly by bindings, among other things.
Comment 1 Matthew Barnes 2009-12-15 03:19:58 UTC
I have a need for this in Evolution as well.  Different parts of the application share the same GKeyFile and I'd like to be able to reference and unreference it like I do with most everything else.
Comment 2 Christian Persch 2009-12-15 10:40:43 UTC
Refcounting GKeyFile was rejected in bug 301034.
Comment 3 Matthew Barnes 2009-12-15 12:24:25 UTC
On grounds that aren't valid anymore.  GArray, GAsyncQueue, GByteArray, GHashTable, GHook, GIOChannel, GMainContext, GMainLoop, GMappedFile, GPtrArray, GRegex, GSource and GTree are all reference counted these days.
Comment 4 Johan (not receiving bugmail) Dahlin 2010-04-07 15:08:49 UTC
*** Bug 615070 has been marked as a duplicate of this bug. ***
Comment 5 Johan (not receiving bugmail) Dahlin 2010-04-07 15:09:08 UTC
Created attachment 158129 [details] [review]
[GKeyFile] Add g_key_file_copy and make it a boxed

Make GKeyFile a boxed so it can be used from language bindings.

https://bugzilla.gnome.org/show_bug.cgi?id=615070
Comment 6 Johan (not receiving bugmail) Dahlin 2010-04-07 15:10:35 UTC
Annotations for introspection bindings will go into the gobject-introspection module for now.
Comment 7 Johan (not receiving bugmail) Dahlin 2010-04-07 15:23:29 UTC
Although it would probably be better to make it a reference counted structure, as per bug 301034
Comment 8 Johan (not receiving bugmail) Dahlin 2010-04-07 16:20:53 UTC
Created attachment 158138 [details] [review]
[GKeyFile] Register a boxed type

Register a boxed type for the GKeyFile struct, this will
make it possible to use it from language bindings.

This is a simplified patch which doesn't export any new APIs,
it's just exposes the current interface (copy/free) of GKeyFile
to the GObject type system.
Comment 9 Christian Persch 2010-04-08 10:17:43 UTC
g_slice_copy() is not a valid copy func for GKeyFile. Free the original keyfile, and the copy's members will point to freed memory.
Comment 10 Johan (not receiving bugmail) Dahlin 2010-04-08 19:09:44 UTC
Created attachment 158230 [details] [review]
[GKeyFile] Add refcounting API

Based on the patch by Christian Persch and Emmanuele Bassi.

Author: Christian Persch
Signed-off-by: Johan Dahlin
Comment 11 Johan (not receiving bugmail) Dahlin 2010-04-08 19:09:56 UTC
Created attachment 158232 [details] [review]
[GKeyFile] Register a boxed type

Register a boxed type for the GKeyFile struct, this will
make it possible to use it from language bindings.
Comment 12 Javier Jardón (IRC: jjardon) 2010-04-09 12:18:19 UTC
*** Bug 301034 has been marked as a duplicate of this bug. ***
Comment 13 Emmanuele Bassi (:ebassi) 2010-04-09 16:23:28 UTC
Review of attachment 158232 [details] [review]:

::: gobject/gboxed.c
@@ +304,3 @@
+{
+g_key_file_get_type(void)
+GType

shouldn't we use GOnce for thread safety here?
Comment 14 Johan (not receiving bugmail) Dahlin 2010-04-10 11:55:43 UTC
Created attachment 158359 [details] [review]
[GKeyFile] Register a boxed type

Register a boxed type for the GKeyFile struct, this will
make it possible to use it from language bindings.

This is an updated patch which uses GOnce for thread-safety
as suggested by Emmanuele.
Comment 15 Matthias Clasen 2011-06-22 15:06:22 UTC
Review of attachment 158230 [details] [review]:

::: glib/gkeyfile.c
@@ +706,3 @@
+ * Returns: the same @key_file.
+ *
+ * Since: 2.24

Since tag needs to say 2.30 by now, time flies...

@@ +712,3 @@
+{
+  g_return_val_if_fail (key_file != NULL, NULL);
+  g_return_val_if_fail (key_file->ref_count > 0, NULL);

I've removed these kinds of checks for ref_count > 0 from similar places recently.
They do nonatomic access, so its kinda unsafe. And using an atomic access for this 
seems like overkill.

@@ +745,3 @@
+ * reaches zero, frees the key file and all its allocated memory.
+ *
+ * Since: 2.24

2.30 here, too.

@@ +751,3 @@
+{
+  g_return_if_fail (key_file != NULL);
+  g_return_if_fail (key_file->ref_count > 0);

Same here.

@@ +753,3 @@
+  g_return_if_fail (key_file->ref_count > 0);
+
+  if (g_atomic_int_exchange_and_add (&key_file->ref_count, -1) - 1 == 0)

Should use g_atomic_int_dec_and_test here.
Comment 16 Matthias Clasen 2011-06-22 15:07:34 UTC
Review of attachment 158359 [details] [review]:

This one looks fine (of course, depends on the earlier patch)
Comment 17 Matthias Clasen 2011-06-22 15:08:42 UTC
Review of attachment 158359 [details] [review]:

Oh, but it needs to get a define in glib-types.h, with a proper Since: tag.
Comment 18 Giovanni Campagna 2011-06-22 16:15:22 UTC
*** Bug 652880 has been marked as a duplicate of this bug. ***
Comment 19 Giovanni Campagna 2011-06-22 16:23:31 UTC
Created attachment 190450 [details] [review]
GKeyFile: Add refcounting API

Adds g_key_file_ref and g_key_file_unref, to be used by a future
GKeyFile boxed type for language bindings.

Based on the patch by Christian Persch and Emmanuele Bassi.

------
Updated to use g_atomic_int_dec_and_test. Updated Since. Removed ref_count checks.

Author: Christian Persch
Signed-off-by: Johan Dahlin
Signed-off-by: Giovanni Campagna
Comment 20 Giovanni Campagna 2011-06-22 16:32:14 UTC
Created attachment 190452 [details] [review]
glib: turn GKeyFile into a boxed for introspection

Using the new refcounting API, introduce a boxed type wrapping
GKeyFile and expose it introspection bindings in glib-types.h
Comment 21 Giovanni Campagna 2011-06-22 16:32:37 UTC
Created attachment 190453 [details] [review]
GKeyFile: improve introspection annotations

Ensure that all methods that take or return arrays are annotated
(including length). Mark ref, unref and free methods as (skip).
Comment 22 Colin Walters 2011-06-24 00:04:07 UTC
Review of attachment 190450 [details] [review]:

Feel free to commit after one minor change.

::: glib/gkeyfile.c
@@ +90,3 @@
   gchar **locales;
+
+  volatile gint ref_count;

Can you put the refcount at the start of the structure?  I am thinking about adding generic "refcounted boxed" handling, and that's easy if the refcount is always at the start.
Comment 23 Colin Walters 2011-06-24 00:04:51 UTC
Review of attachment 190452 [details] [review]:

This one needs to add to gobject.symbols too.
Comment 24 Colin Walters 2011-06-24 00:06:55 UTC
Review of attachment 190453 [details] [review]:

This all looks good, thanks!
Comment 25 Matthias Clasen 2011-09-18 00:18:49 UTC
Given that we have already branched for 2.30, this is probably good to go in now.