Re: RFC: glocal - automatically freeing memory when it goes out of scope
On 05/29/2012 10:21 PM, Ben Pfaff wrote: Mikkel Kamstrup Erlandsenmikkel.kamst...@canonical.com writes: On 05/29/2012 07:23 PM, Ben Pfaff wrote: Mikkel Kamstrup Erlandsenmikkel.kamst...@canonical.com writes: I have been looking at gcc's cleanup attribute[1] that allows one to specify a callback that will be invoked when a variable goes out of scope. This allows one to play with automatically freeing resources. Is it possible to combine use of this GCC-specific attribute with the concept in Doug Gwyn's mostly-portable alloca implementation, so that you would end up with something that works pretty much everywhere (but is more efficient with GCC)? Here's one copy of the Doug Gwyn alloca that just happened to be on the top of the results of my web search: ftp://ftp.dante.de/tex-archive/fonts/utilities/ps2mf/alloca.c There is already g_alloca() and g_newa() for allocating on the stack. I'm not suggesting an implementation of an alloca-like function based on these ideas; as you say, glib already has alloca-like functions. I'm suggesting that one could use the idea behind the Doug Gwyn portable alloca to implement something like, or at least related to, the GCC cleanup attribute even when GCC is not the compiler in use. (However, the attribute syntax wouldn't work, and the interface would otherwise need to be different.) Sorry, I misunderstood you then :-) I am afraid the answer is no. alloca() does not provide a callback when cleaning up, and we need that for anything that needs a teradown function - which is basically everything that is not a string... Also this portable alloca() mentions in the docs that memory is not guaranteed to be freed when you leave the scope, but mayb happen higher up in the stack - and there even should be a mainloop driving garbage collection with alloca(0) as well. This means that the automagic lock management I added wouldn't work fx. Cheers, Mikkel ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
On 05/30/2012 05:17 AM, Paul Davis wrote: On Wed, May 30, 2012 at 3:22 AM, Mikkel Kamstrup Erlandsen mikkel.kamst...@canonical.com mailto:mikkel.kamst...@canonical.com wrote: alloca() does not provide a callback when cleaning up, and we need that for anything that needs a teradown function - which is basically everything that is not a string... those who refuse to acknowledge the role of the compiler in supporting object-oriented programming are doomed to repeat cfront :) What's wrong with cfront? I want cfront back! /me runs b ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
Mikkel Kamstrup Erlandsen mikkel.kamst...@canonical.com writes: I have been looking at gcc's cleanup attribute[1] that allows one to specify a callback that will be invoked when a variable goes out of scope. This allows one to play with automatically freeing resources. Is it possible to combine use of this GCC-specific attribute with the concept in Doug Gwyn's mostly-portable alloca implementation, so that you would end up with something that works pretty much everywhere (but is more efficient with GCC)? Here's one copy of the Doug Gwyn alloca that just happened to be on the top of the results of my web search: ftp://ftp.dante.de/tex-archive/fonts/utilities/ps2mf/alloca.c ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
Mikkel Kamstrup Erlandsen mikkel.kamst...@canonical.com writes: On 05/29/2012 07:23 PM, Ben Pfaff wrote: Mikkel Kamstrup Erlandsenmikkel.kamst...@canonical.com writes: I have been looking at gcc's cleanup attribute[1] that allows one to specify a callback that will be invoked when a variable goes out of scope. This allows one to play with automatically freeing resources. Is it possible to combine use of this GCC-specific attribute with the concept in Doug Gwyn's mostly-portable alloca implementation, so that you would end up with something that works pretty much everywhere (but is more efficient with GCC)? Here's one copy of the Doug Gwyn alloca that just happened to be on the top of the results of my web search: ftp://ftp.dante.de/tex-archive/fonts/utilities/ps2mf/alloca.c There is already g_alloca() and g_newa() for allocating on the stack. I'm not suggesting an implementation of an alloca-like function based on these ideas; as you say, glib already has alloca-like functions. I'm suggesting that one could use the idea behind the Doug Gwyn portable alloca to implement something like, or at least related to, the GCC cleanup attribute even when GCC is not the compiler in use. (However, the attribute syntax wouldn't work, and the interface would otherwise need to be different.) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
On Sun, 2012-05-27 at 11:20 +0200, Mikkel Kamstrup Erlandsen wrote: Attached a new version as a late update to this thread, but better than nothing I hope :-) I still haven't gotten around to sticking it in libegg (or even a bug). Sorry! I'll do that when I am more happy with what I have. glocal_string is really glocal_free, or at least that's what I called it in my version, because you can use it on anything that you know can be freed with g_free(), which isn't just strings. For example, private structures. - Added glocal_defer(callback, arg): Calls @callback with @arg when leaving the current scope Hmm. What's the use case for this one? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
On 05/29/2012 05:36 PM, Colin Walters wrote: On Sun, 2012-05-27 at 11:20 +0200, Mikkel Kamstrup Erlandsen wrote: Attached a new version as a late update to this thread, but better than nothing I hope :-) I still haven't gotten around to sticking it in libegg (or even a bug). Sorry! I'll do that when I am more happy with what I have. glocal_string is really glocal_free, or at least that's what I called it in my version, because you can use it on anything that you know can be freed with g_free(), which isn't just strings. For example, private structures. Ah, of course. Makes a lot more sense. - Added glocal_defer(callback, arg): Calls @callback with @arg when leaving the current scope Hmm. What's the use case for this one? I use it for the automatic unlocking macros for example. Or to close a stream/fd, or to do manual profiling of hot spots - you just have one ifdef block at the top, and not littered all over the function at all return points, or if you're building some kind of message that you must always write() to a pipe before returning, etc. Cheers, Mikkel ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
On 05/29/2012 07:23 PM, Ben Pfaff wrote:
Mikkel Kamstrup Erlandsenmikkel.kamst...@canonical.com writes:
I have been looking at gcc's cleanup attribute[1] that allows one to
specify a callback that will be invoked when a variable goes out of
scope. This allows one to play with automatically freeing resources.
Is it possible to combine use of this GCC-specific attribute with
the concept in Doug Gwyn's mostly-portable alloca
implementation, so that you would end up with something that
works pretty much everywhere (but is more efficient with GCC)?
Here's one copy of the Doug Gwyn alloca that just happened to be
on the top of the results of my web search:
ftp://ftp.dante.de/tex-archive/fonts/utilities/ps2mf/alloca.c
There is already g_alloca() and g_newa() for allocating on the stack.
I'va also been thinking quite a lot about how we could leverage stack
allocation to get rid of even more memory management hassles.
One could conceivably introduce *a() variants of various key calls, like
g_strdupa(), g_strdupa_printf(), maybe array types g_{ptr_,}array_newa,
etc. Noting that GList and GSList doesn't strictly need special variants
as you can already stack allocate them as they are fully defined
structs. Although g_list_prependa() and friends would be more convenient.
It will bloat the API quite a lot though that's why I never seriously
proposed it. Another solution would be to have a g_push/pop_allocator()
kind of thing. Didn't think too deeply about it though.
Cheers,
Mikkel
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
On 10 April 2012 11:28, Mikkel Kamstrup Erlandsen
mikkel.kamst...@canonical.com wrote:
On 04/04/2012 05:35 AM, Colin Walters wrote:
On Wed, 2011-11-16 at 21:05 +0100, Mikkel Kamstrup Erlandsen wrote:
Hi all,
I have been looking at gcc's cleanup attribute[1] that allows one to
specify a callback that will be invoked when a variable goes out of
scope. This allows one to play with automatically freeing resources.
So this is frankly pretty cool - but we can't make GLib/GTK+
dependent on GNU C.
Totally agreed. (although cursory research seems to indicate this will work
on clang as well, I realize glib is used with many other compilers)
I could imagine using this in some gcc/Linux-specific parts of GNOME
though; care to polish up the header, and we could put it somewhere it
can be shared/reused (not sure where...libegg?)
Sure, I have some updates lying around I want to apply as well (fx. Go-style
deferred method calls), then I repost an updated version.
Attached a new version as a late update to this thread, but better
than nothing I hope :-) I still haven't gotten around to sticking it
in libegg (or even a bug). Sorry! I'll do that when I am more happy
with what I have.
In any case, here are some updates:
- Added glocal_defer(callback, arg): Calls @callback with @arg when
leaving the current scope
- Add convenience lock/unlock macros for GMutex, GRecMutex, and
GRWLock. They grab a given lock and unlock it when leaving the current
scope
- Renamed to glib-gnuc.h since I find that more appropriate, and
better fits with clang using the gnuc profile (for those with those
tendencies).
Cheers,
Mikkel
/* glib-gnuc.h: gcc specific extensions to glib
*
* Copyright (C) 2011 Canonical Ltd
* 2012 Mikkel Kamstrup Erlandsen
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General
* Public License along with this library; if not, write to the
* Free Software Foundation, Inc., 59 Temple Place, Suite 330,
* Boston, MA 02111-1307, USA.
*
* Author: Mikkel Kamstrup Erlandsen mikkel.kamst...@canonical.com
*/
#include glib.h
#include glib-object.h
#ifndef __GLIB_GNUC_H__
#define __GLIB_GNUC_H__
#ifndef __GNUC__
#error This project uses non-standard GNU C extensions and requires 'gcc´ to compile.
#endif
G_BEGIN_DECLS
/**
* glocal_string:
*
* Macro declaring that a null terminated string be automatically freed when it
* goes out of scope. For example:
* informalexampleprogramlisting
* if (print_hello_world)
* {
* glocal_string gchar *str = g_strdup (world!);
* g_printf (Hello %s\n, str);
* // at this point 'str´ is automatically freed
* }
* /programlisting/informalexample
* Beware that if you assign the value of the local string to some other string
* that there is no transfer of ownership. The local variable will still be
* freed when it goes out of scope. If you want to avoid this you can set the
* local variable to %NULL. The following snippet is thus legal:
* informalexampleprogramlisting
* gchar *snooped_string;
* if (print_hello_world)
* {
* glocal_string gchar *str = g_strdup (world!);
* g_printf (Hello %s\n, str);
* snooped_string = str;
* str = NULL;
* // at this point 'str´ is NULL and nothing will happen
* }
* g_printf (Woohoo. I just stole the whole %s\n, snooped_string);
* g_free (snooped_string);
* /programlisting/informalexample
*/
#define glocal_string __attribute__ ((cleanup(_glocal_free_str)))
static void
_glocal_free_str (gchar **strp)
{
if (strp *strp)
g_free (*strp);
}
/**
* glocal_object:
*
* Macro declaring that a GObject will be automatically unreferenced when
* it goes out of scope.
*
* Example:
* informalexampleprogramlisting
* glocal_object GFile *file = g_file_new_for_path (/tmp);
* glocal_string gchar *basename = g_file_get_basename (file);
* g_printf (Basename is '%s'\n, basename);
*
* // The two variables file and basename are automatically freed
* /programlisting/informalexample
*
* If you want to avoid freeing the object when it goes out of scope you can
* set the pointer to %NULL. See glocal_string() for an example.
*/
#define glocal_object __attribute__ ((cleanup(_glocal_unref_object)))
static void
_glocal_unref_object (void *ptraddr)
{
GObject **objp = (GObject**) ptraddr;
if (objp *objp)
g_object_unref (*objp);
}
/**
* glocal_defer:
* @cb: Callback to invoke when
Re: RFC: glocal - automatically freeing memory when it goes out of scope
On 04/04/2012 05:35 AM, Colin Walters wrote: On Wed, 2011-11-16 at 21:05 +0100, Mikkel Kamstrup Erlandsen wrote: Hi all, I have been looking at gcc's cleanup attribute[1] that allows one to specify a callback that will be invoked when a variable goes out of scope. This allows one to play with automatically freeing resources. So this is frankly pretty cool - but we can't make GLib/GTK+ dependent on GNU C. Totally agreed. (although cursory research seems to indicate this will work on clang as well, I realize glib is used with many other compilers) I could imagine using this in some gcc/Linux-specific parts of GNOME though; care to polish up the header, and we could put it somewhere it can be shared/reused (not sure where...libegg?) Sure, I have some updates lying around I want to apply as well (fx. Go-style deferred method calls), then I repost an updated version. Cheers, Mikkel ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
- Original Message - On Tue, 03 Apr 2012 23:35:46 -0400 Colin Walters walt...@verbum.org wrote: On Wed, 2011-11-16 at 21:05 +0100, Mikkel Kamstrup Erlandsen wrote: Hi all, I have been looking at gcc's cleanup attribute[1] that allows one to specify a callback that will be invoked when a variable goes out of scope. This allows one to play with automatically freeing resources. So this is frankly pretty cool - but we can't make GLib/GTK+ dependent on GNU C. I guess that for glib these things are matters of degree rather than principle. glib now uses gcc's constructor and destructor attributes since, I think, version 2.32 (I believe that is when gconstructor.h first appeared), presumably on the grounds that, although non-standard, they are also found in most mainstream compilers likely to be used with glib. What it uses is constructors, not particularly the gcc ones (although they are used with gcc). On MSVC and SunCC we use the native compiler methods to create constructors and destructors. Constructors are a required feature of C++ and all OSes that want to support C++ have to somehow handle them, and its also pretty common for C code to use them. So, I don't think its comparable at all to something that is specific to gcc only. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
gcc's constructor and destructor attributes as I understand them are principally used in connection with the loading and unloading of shared libraries at program start-up and close down, although I imagine they have other uses. If you say those may require OS support I will believe you (certainly shared libraries do), and in terms of ubiquity I do not dispute that their use and/or availability for C is more widespread than, say, cleanup attributes. I might have been a bit sloppy with my words, but the following C++ code, in a shared library: MyClass my_object; Needs to have the MyClass constructor for the static object my_object run before the main() function in your application. This is identical to attribute constructor (in fact, implementation wise thats how this works in C++). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
On Thu, 05 Apr 2012 10:58:24 -0400 (EDT) Alexander Larsson al...@redhat.com wrote: [snip] I might have been a bit sloppy with my words, but the following C++ code, in a shared library: MyClass my_object; Needs to have the MyClass constructor for the static object my_object run before the main() function in your application. This is identical to attribute constructor (in fact, implementation wise thats how this works in C++). Ah, I understand you. And of course, if not in a shared library also. (C++ programmers soon learn to avoid static initialization of objects in namespace scope, except for the most trivial of uses, because the order of initialization between translation units is unspecified. I know gcc makes priority specification available as a GNU extension for C++, but that is only really useful in C++ if you don't link outside your own code and stick to gcc, so lazy initialization is almost always better.) Chris ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
On Thu, 2012-04-05 at 17:47 +0100, Chris Vine wrote: On Thu, 05 Apr 2012 10:58:24 -0400 (EDT) Alexander Larsson al...@redhat.com wrote: [snip] I might have been a bit sloppy with my words, but the following C++ code, in a shared library: MyClass my_object; Needs to have the MyClass constructor for the static object my_object run before the main() function in your application. This is identical to attribute constructor (in fact, implementation wise thats how this works in C++). Ah, I understand you. And of course, if not in a shared library also. There's also the fact that GLib's use of constructors is very local, and if it really came to the point where one needed to make it work on some old version of HP-UX or whatever, at worst one could hack up a patch to just call the constructor code early in main() of whatever program fairly easily. Were we to make pervasive use of the cleanup attribute, then someone attempting to remove the dependency would have to patch (in a nontrivial way) *every function* that used it. It'd be a significant amount of error-prone work. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
On Tue, 03 Apr 2012 23:35:46 -0400 Colin Walters walt...@verbum.org wrote: On Wed, 2011-11-16 at 21:05 +0100, Mikkel Kamstrup Erlandsen wrote: Hi all, I have been looking at gcc's cleanup attribute[1] that allows one to specify a callback that will be invoked when a variable goes out of scope. This allows one to play with automatically freeing resources. So this is frankly pretty cool - but we can't make GLib/GTK+ dependent on GNU C. I guess that for glib these things are matters of degree rather than principle. glib now uses gcc's constructor and destructor attributes since, I think, version 2.32 (I believe that is when gconstructor.h first appeared), presumably on the grounds that, although non-standard, they are also found in most mainstream compilers likely to be used with glib. Chris ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
On Wed, 2011-11-16 at 21:05 +0100, Mikkel Kamstrup Erlandsen wrote: Hi all, I have been looking at gcc's cleanup attribute[1] that allows one to specify a callback that will be invoked when a variable goes out of scope. This allows one to play with automatically freeing resources. So this is frankly pretty cool - but we can't make GLib/GTK+ dependent on GNU C. I could imagine using this in some gcc/Linux-specific parts of GNOME though; care to polish up the header, and we could put it somewhere it can be shared/reused (not sure where...libegg?) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
On 11/21/2011 04:54 PM, Hub Figuière wrote: On 21/11/11 07:34 AM, Mikkel Kamstrup Erlandsen wrote: This is precisely my motivation for introducing this; ie. not to catch leaks, but to tidy the code. Bigger code bases almost always grow functions with multiple returns - notably when error handling is introduced. Automatic freeing can cut down on that complexity considerably. On less complex functions it can still add clarity by making the actual algorithms more apparent in between all the g_free()s and g_object_unref()s. Which is basically what my counter-proposal of g_object_autorelease() is about. That's exactly the use case in Objective-C with Cocoa that, unlike C++, does not have scope based life cycle of object, but supports exceptions. Also to make it more useful with Glib, we would need to have actually containers implemented as GObjects. I am guessing that you expect this autorelease pool to trigger a garbage collection in an idle call on the mainloop or something? Assuming yes; I can see that this has its use cases, but also some pretty huge drawbacks. Like 1) needing a mainloop, and 2) being susceptible to memory ballooning with something like a for-loop doing lots of string manipulations. And 2) is a very common use case for automatic cleanup since looping often has a few early-breaks with the required extra cleanup logic. That said, I am not against the concept either. It does have the advantage on ref counted types that any function on the call stack can grab a ref before the next idle. So it can work over returns and such. Cheers, Mikkel ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
On 11/21/2011 04:51 PM, Ross Burton wrote: On 21 November 2011 15:43, Dominic Lachowiczdomlachow...@gmail.com wrote: If you want this sort of behavior, use a language like C++ that supports stack-allocated objects natively. GtkMM and GlibMM already do this wonderfully. Using a GNU-C ism which probably won't work with most other C compilers (MSVC, LLVM, ICC, ...) feels wrong to me. We need a micro-C++ binding that looks exactly like traditional GObject C but also hooks up the nice features like stack allocated objects. I don't like C++ but I'd consider a C++ compiler to compile my C code if it could simplify memory management dramatically for almost free. :) Stack allocated GObjects would be sweet, but is unfortunately quite far from becoming a realistic option. Compiling C code with a C++ compiler also brings other interesting things along; like name mangling and the fact that a struct is no longer a plain old C struct, but really a C++ class. And generally mixing two type systems and two memory management systems brings too many interesting quirks along that I don't really want to go there. We've done this a *lot* in Unity and related projects and I never liked it. Cheers, Mikkel ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
On Tue, 2011-11-22 at 09:03 +0100, Mikkel Kamstrup Erlandsen wrote: On 11/21/2011 04:54 PM, Hub Figuière wrote: On 21/11/11 07:34 AM, Mikkel Kamstrup Erlandsen wrote: This is precisely my motivation for introducing this; ie. not to catch leaks, but to tidy the code. Bigger code bases almost always grow functions with multiple returns - notably when error handling is introduced. Automatic freeing can cut down on that complexity considerably. On less complex functions it can still add clarity by making the actual algorithms more apparent in between all the g_free()s and g_object_unref()s. Which is basically what my counter-proposal of g_object_autorelease() is about. That's exactly the use case in Objective-C with Cocoa that, unlike C++, does not have scope based life cycle of object, but supports exceptions. Also to make it more useful with Glib, we would need to have actually containers implemented as GObjects. I am guessing that you expect this autorelease pool to trigger a garbage collection in an idle call on the mainloop or something? Assuming yes; I can see that this has its use cases, but also some pretty huge drawbacks. Like 1) needing a mainloop, and 2) being susceptible to memory ballooning with something like a for-loop doing lots of string manipulations. And 2) is a very common use case for automatic cleanup since looping often has a few early-breaks with the required extra cleanup logic. Auto-release pools come with a hard requirement of the user understanding them, that being said after having used them I can say that it's a practical and comfortable idea as specially when compared to our floating ref solution (i.e. the floating object is owned by noone... but somehow needs to be ref_sinked and unreffed anyway) So... for instance, when implementing an iterative api such as gtk_container_foreach(), a pool should be pushed onto the stack: g_autorelease_pool_push (); for (i in children) user_callback (child, data); g_autorelease_pool_pop (); Pushing a pool puts one on top of the stack, popping a pool will release all of the references which it has accumulated during it's life-cycle. Authors of programs in Cocoa need to understand this and manually push/pop autorelease pools when such memory balooning might be a problem (again, a much simpler concept to cope with than floating refs IMO). Similarly the GMainLoop, by virtue of being a loop, should also push a pool onto the autorelease pool stack and pop it while dispatching GSources (and this is where you get the extra 'unref on mainloop hit' detail). Cheers, -Tristan That said, I am not against the concept either. It does have the advantage on ref counted types that any function on the call stack can grab a ref before the next idle. So it can work over returns and such. Right, you can have functions that return a soft reference like so: return g_object_autorelease (object); But the value can and should only be trusted in the scope of the function calling a function which returns a soft reference (because you never know when your original caller will pop the current pool off of the stack, it becomes conceptually invalid after you run out of the current scope). Cheers, -Tristan Cheers, Mikkel ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
hi; On 22 November 2011 09:44, Tristan Van Berkom trista...@openismus.com wrote: Similarly the GMainLoop, by virtue of being a loop, should also push a pool onto the autorelease pool stack and pop it while dispatching GSources (and this is where you get the extra 'unref on mainloop hit' detail). it's not strictly necessary to have a default behaviour, though. we could have two distinct functions: /* schedules a idle source to release the resources when we re-enter the main loop */ void g_autorelease_pool_pop_in_idle (GAutoreleasePool*); /* releases the resources immediately */ void g_autorelease_pool_pop (GAutoreleasePool*); following the pattern in GIO. for MT applications we could even provide a function to release resources within a specific GMainContext as well, to release the resources in a specific thread instead of the default main context. the obvious issue is: how does this interact with languages that do have a GC, and how does the API work to avoid making the life of developers for high-level languages apps and/or bindings a nightmare. if libraries start using this object for their internal allocations, for instance, or start relying on it when using their API. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
On Tue, Nov 22, 2011 at 4:48 AM, Emmanuele Bassi eba...@gmail.com wrote:
hi;
On 22 November 2011 09:44, Tristan Van Berkom trista...@openismus.com wrote:
Similarly the GMainLoop, by virtue of being a loop,
should also push a pool onto the autorelease pool stack
and pop it while dispatching GSources (and this is where
you get the extra 'unref on mainloop hit' detail).
it's not strictly necessary to have a default behaviour, though.
we could have two distinct functions:
/* schedules a idle source to release the resources when we re-enter
the main loop */
void
g_autorelease_pool_pop_in_idle (GAutoreleasePool*);
/* releases the resources immediately */
void
g_autorelease_pool_pop (GAutoreleasePool*);
following the pattern in GIO. for MT applications we could even
provide a function to release resources within a specific GMainContext
as well, to release the resources in a specific thread instead of the
default main context.
the obvious issue is: how does this interact with languages that do
have a GC, and how does the API work to avoid making the life of
developers for high-level languages apps and/or bindings a nightmare.
if libraries start using this object for their internal allocations,
for instance, or start relying on it when using their API.
Interesting idea for GIO like threaded operations to be sure, I doubt
that language bindings would be the obstacle, language bindings
generally cope with gobject apis to manage gobject ref counts and
are probably already special casing floating references (or by now
they are unconditionally ref_sink'ing *everything* and doing their
own garbage collection)...
I only wonder how to implement an API for that which makes
sense, is very simple to use and allows the author of threaded
async operations to virtually ignore ref-counting (which I think is
the point of the autorelease exercise).
I also predict some confusion when executing an asynchronous
function's top half in the calling thread... i.e. who determines that
that particular function has a separate autorelease pool target
than the default one on top of the stack for that thread ?
Also while running the top half of:
foo_bar_do_something_async ()
{
foo = foo_new (); // assume that foo_new() and bar_new() return
bar = bar_new (); // a soft reference which will be unreffed by
the autorelease pool
/* ... do stuff with foo and bar */
/* Save 'bar' so that it's attached to the async response */
/* Get rid of expensively huge 'foo' right _now_, dont save it
* around for later use in the result callback
*/
g_object_unref (foo);
}
In this case one would presume that 'foo' and 'bar' (if created with a
soft reference)
would be added to the same autorelease pool, even if we could somehow step in
and give that function a new autorelease pool without that function
doing anything
declarative... that function will still want to decide which objects
must be saved
for the async reply.
As soon as the function starts to do something declarative to decide
which memory
lasts until the async callback, of course the whole plan becomes
useless (i.e. we already
have g_object_ref() for that).
Cheers,
-Tristan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
On 22/11/11 01:48 AM, Emmanuele Bassi wrote: the obvious issue is: how does this interact with languages that do have a GC, and how does the API work to avoid making the life of developers for high-level languages apps and/or bindings a nightmare. if libraries start using this object for their internal allocations, for instance, or start relying on it when using their API. I don't see it as being a problem with a GC. GObject does not know about GC and language that have a GC built in already deal with that. This GAutoreleasePool does not change the way object allocatios are managed ; it just provide a mechanism to do the clean at a specific time. For example, from the Gtkmm aspect (C++), I don't see an issue. Hub ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
On 11/22/2011 10:24 PM, Hub Figuière wrote: On 22/11/11 01:48 AM, Emmanuele Bassi wrote: the obvious issue is: how does this interact with languages that do have a GC, and how does the API work to avoid making the life of developers for high-level languages apps and/or bindings a nightmare. if libraries start using this object for their internal allocations, for instance, or start relying on it when using their API. I don't see it as being a problem with a GC. GObject does not know about GC and language that have a GC built in already deal with that. I don't see it as an issue for pygobject either, as pygobject already deal with objects being destroyed from C code (as would probably do any bindings since this is basically what happens to all children of a widget if you destroy it). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
On 16/11/11 12:05 PM, Mikkel Kamstrup Erlandsen wrote: So; what say you? If there is interest I'll gladly polish it up for inclusion. There are also tonnes of other low hanging fruits like freeing other ref counted types, closing of streams, etc. How about a g_autorelease_pool() or something like that? (see NSAutoreleasPool in GNUStep / Cocoa) For those who don't know, basically you would do a g_object_autorelease() on a (refcounted) object you want to unref in the short term but keep long enough to be ref elsewhere. The actual unref is performed when the outer main loop runs or when the autorelease pool is destroy. (that's the pattern in GNUStep / Cocoa) And it might even actually work with floating references and it does not need a specific C compiler extension or C++. Hub PS: and if that whole thing has already been debated and rejected, just say so. I might have been under a rock at that time or something. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
Le lundi 21 novembre 2011 à 00:00 -0800, Hub Figuière a écrit : On 16/11/11 12:05 PM, Mikkel Kamstrup Erlandsen wrote: So; what say you? If there is interest I'll gladly polish it up for inclusion. There are also tonnes of other low hanging fruits like freeing other ref counted types, closing of streams, etc. How about a g_autorelease_pool() or something like that? (see NSAutoreleasPool in GNUStep / Cocoa) For those who don't know, basically you would do a g_object_autorelease() on a (refcounted) object you want to unref in the short term but keep long enough to be ref elsewhere. The actual unref is performed when the outer main loop runs or when the autorelease pool is destroy. (that's the pattern in GNUStep / Cocoa) And it might even actually work with floating references and it does not need a specific C compiler extension or C++. I often though it would be useful to return a ref and unref in an idle cb, to let a chance to the caller to keep the ownership, and still not forcing every caller to always have to care about memory management. It is trivial to implement, but since it is not usual in glib APIs, I never did it. Regards, Xavier Claessens. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
if (1)
{
glocal_object GFile *file = g_file_new_for_path (/tmp);
glocal_string gchar *basename = g_file_get_basename (file);
g_debug (Basename is '%s', basename);
// look ma' no leaks!
}
This is, of course, cute but I don't think this would actually catch many of the
non-trivial leaks that make it into the code base today. Those are typically
not scope based -- possibly because the attention span of the average
programmer is long enough to cover the writing of a whole function, ;-)
The current serious leak cases I see are:
* The dispose or finalize method of an object type fails to free some
stuff. This is
quite common.
* Cyclical links. The resulting leaks are typically quite big.
A case scope-based destructors would handle is this:
* Multiple return statements, typically for error handling, where one or more
branches forget to free stuff. Cursory valgrinding doesn't catch this because
the code doesn't get exercised.
The case isn't uncommon, per se, but programs don't hit the cases often.
M.
PS: The situation where scope-based destruction is important is for languages
such as C++ with exceptions in use. C with GObject is not such a language.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
On 11/21/2011 03:45 PM, Morten Welinder wrote:
if (1)
{
glocal_object GFile *file = g_file_new_for_path (/tmp);
glocal_string gchar *basename = g_file_get_basename (file);
g_debug (Basename is '%s', basename);
// look ma' no leaks!
}
This is, of course, cute but I don't think this would actually catch many of the
non-trivial leaks that make it into the code base today. Those are typically
not scope based -- possibly because the attention span of the average
programmer is long enough to cover the writing of a whole function, ;-)
The current serious leak cases I see are:
* The dispose or finalize method of an object type fails to free some
stuff. This is
quite common.
* Cyclical links. The resulting leaks are typically quite big.
A case scope-based destructors would handle is this:
* Multiple return statements, typically for error handling, where one or more
branches forget to free stuff. Cursory valgrinding doesn't catch this
because
the code doesn't get exercised.
The case isn't uncommon, per se, but programs don't hit the cases often.
This is precisely my motivation for introducing this; ie. not to catch
leaks, but to tidy the code. Bigger code bases almost always grow
functions with multiple returns - notably when error handling is
introduced. Automatic freeing can cut down on that complexity
considerably. On less complex functions it can still add clarity by
making the actual algorithms more apparent in between all the g_free()s
and g_object_unref()s.
Cheers,
Mikkel
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
If you want this sort of behavior, use a language like C++ that
supports stack-allocated objects natively. GtkMM and GlibMM already do
this wonderfully. Using a GNU-C ism which probably won't work with
most other C compilers (MSVC, LLVM, ICC, ...) feels wrong to me.
On Mon, Nov 21, 2011 at 10:34 AM, Mikkel Kamstrup Erlandsen
mikkel.kamst...@canonical.com wrote:
On 11/21/2011 03:45 PM, Morten Welinder wrote:
if (1)
{
glocal_object GFile *file = g_file_new_for_path (/tmp);
glocal_string gchar *basename = g_file_get_basename (file);
g_debug (Basename is '%s', basename);
// look ma' no leaks!
}
This is, of course, cute but I don't think this would actually catch many
of the
non-trivial leaks that make it into the code base today. Those are
typically
not scope based -- possibly because the attention span of the average
programmer is long enough to cover the writing of a whole function, ;-)
The current serious leak cases I see are:
* The dispose or finalize method of an object type fails to free some
stuff. This is
quite common.
* Cyclical links. The resulting leaks are typically quite big.
A case scope-based destructors would handle is this:
* Multiple return statements, typically for error handling, where one or
more
branches forget to free stuff. Cursory valgrinding doesn't catch this
because
the code doesn't get exercised.
The case isn't uncommon, per se, but programs don't hit the cases often.
This is precisely my motivation for introducing this; ie. not to catch
leaks, but to tidy the code. Bigger code bases almost always grow functions
with multiple returns - notably when error handling is introduced. Automatic
freeing can cut down on that complexity considerably. On less complex
functions it can still add clarity by making the actual algorithms more
apparent in between all the g_free()s and g_object_unref()s.
Cheers,
Mikkel
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
--
I like to pay taxes. With them, I buy civilization. -- Oliver Wendell Holmes
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
On 21 November 2011 15:43, Dominic Lachowicz domlachow...@gmail.com wrote: If you want this sort of behavior, use a language like C++ that supports stack-allocated objects natively. GtkMM and GlibMM already do this wonderfully. Using a GNU-C ism which probably won't work with most other C compilers (MSVC, LLVM, ICC, ...) feels wrong to me. We need a micro-C++ binding that looks exactly like traditional GObject C but also hooks up the nice features like stack allocated objects. I don't like C++ but I'd consider a C++ compiler to compile my C code if it could simplify memory management dramatically for almost free. :) Ross ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
On 21/11/11 07:34 AM, Mikkel Kamstrup Erlandsen wrote: This is precisely my motivation for introducing this; ie. not to catch leaks, but to tidy the code. Bigger code bases almost always grow functions with multiple returns - notably when error handling is introduced. Automatic freeing can cut down on that complexity considerably. On less complex functions it can still add clarity by making the actual algorithms more apparent in between all the g_free()s and g_object_unref()s. Which is basically what my counter-proposal of g_object_autorelease() is about. That's exactly the use case in Objective-C with Cocoa that, unlike C++, does not have scope based life cycle of object, but supports exceptions. Also to make it more useful with Glib, we would need to have actually containers implemented as GObjects. Hub ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
On 21/11/11 07:51 AM, Ross Burton wrote: We need a micro-C++ binding that looks exactly like traditional GObject C but also hooks up the nice features like stack allocated objects. I don't like C++ but I'd consider a C++ compiler to compile my C code if it could simplify memory management dramatically for almost free. :) You can do that just by using a boost::intrusive_ptr - or an equivalent. But then you are gonna hit a lot of cases where you wish it was just C++ as you won't be able to pass it directly to glib or gtk functions, and you'll have to play nice with casting. Not saying it is impossible, but that it can get ugly. Hub ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: glocal - automatically freeing memory when it goes out of scope
On Mon, 2011-11-21 at 00:00 -0800, Hub Figuière wrote: On 16/11/11 12:05 PM, Mikkel Kamstrup Erlandsen wrote: So; what say you? If there is interest I'll gladly polish it up for inclusion. There are also tonnes of other low hanging fruits like freeing other ref counted types, closing of streams, etc. How about a g_autorelease_pool() or something like that? (see NSAutoreleasPool in GNUStep / Cocoa) Just throwing this out there randomly... I would buy autorelease pools over GtkObject's 'floating ref' concept any day of the week and twice on sunday. Unfortunately GtkObject's floating reference concept has bled so deep into GObject by now and I think we're stuck with it (although the idea of reimplementing GInitiallyUnowned to just create an autoreleased object from the constructor is... really intriguing...) For those who don't know, basically you would do a g_object_autorelease() on a (refcounted) object you want to unref in the short term but keep long enough to be ref elsewhere. The actual unref is performed when the outer main loop runs or when the autorelease pool is destroy. (that's the pattern in GNUStep / Cocoa) And it might even actually work with floating references and it does not need a specific C compiler extension or C++. Hub PS: and if that whole thing has already been debated and rejected, just say so. I might have been under a rock at that time or something. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
