Re: g_main_context_depth()

[Stefan Westerfeld <stefan space twc de>]

   Hi!

On Mon, Jan 05, 2004 at 04:40:01PM -0500, Owen Taylor wrote:
> Tim asked me for something like the following.
> 
>  int g_main_context_depth (GMainContext *context);
> 
>  Returns the depth of the stack of calls to
>  g_main_context_dispatch() on @context in the current thread.
>  That is, when called from the toplevel, it gives 0. When
>  called from within a callback from g_main_context_iteration()
>  (or g_main_loop_run(), etc.) it returns 1. When called from within 
>  a callback to a recursive call to g_main_context_iterate(),
>  it returns 2. And so forth.
>
> [...]
>
> As can be seen from the above, I'm not crazy about adding the function
>   
>  - I don't know any valid uses of it other than the one case described
>    in detail above, which seems like a lame replacement for alloca()
>    essentially. (The one advantage is that you can return the allocated
>    memory to a caller. The huge disadvantage is that you can get
>    into difficulties if you start using memory from within a loop.)
> 
>  - It's very tempting to use it in situations that aren't 
>    appropriate. (The equivalent Qt function that inspired the request
>    has been deprecated, though the docs don't elaborate on why.)
> 
> I'd be interested to hear if other people have uses for this function,
> or if Tim wants to say a bit more on why main-looop-depth controlled
> GC is cool enough to be worth special support in GObject.

I agree with you: the function is problematic when not used in the right
place. So maybe there should be a hint about this in the documentation. But
whenever main loops come into place, there appear to be subtle ways of
messing up your program, because of the reentrancy issues.

However, I can give you more details about why Tim and I went with what you
call "lame replacement for alloca()" nevertheless ;). Basically, while
developing yet-another-middleware (SFI), we needed a C language binding for
things like

... (.idl format) ...
namespace Foo {
  record Position {
    Int x;
	Int y;
  };
  class X {
	String   name();
    Position position();
  };
};
...

and choose:

... (generated .h file for the client) ...
const gchar* foo_x_name (SfiProxy foo_x_object);
FooPosition* foo_x_position (SfiProxy foo_x_object);
...

It would be a burden for the caller to free all these SFI allocated data
structures every time he does a call on a SFI object, which is why we came
up with that "simple" garbage collection solution. As you see alloca()
doesn't help at all, because we exactly need the case where values are
returned.

Of course, in the C++ language binding, we don't really need to have this,
because we can use smart pointers to free the data.

But as large parts of BEAST (the only application using SFI right now) are
written in C, not adding the function would quite mess up the code. And even
if it was ported to C++ entierly, still the C API would be unnecessarily hard
to use.

   Cu... Stefan
-- 
  -* Stefan Westerfeld, stefan space twc de (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-