Re: inlining glib functions (Was: public barrier functions)

[Balazs Scheidler <bazsi balabit hu>]

On Mon, 2005-12-12 at 18:44 +0000, Gustavo J. A. M. Carneiro wrote:
> Seg, 2005-12-12 às 19:29 +0100, Balazs Scheidler escreveu:
> [...]
> > 
> > And while I am at it, would it be possible to change the atomic
> > operations to inline functions? I'd think it is much better inline
> > single-instruction functions as otherwise the call overhead is too
> > great.
> 
>   I agree.  Also many other glib functions could be static inline in the
> public header files.  For instance, many of the functions in glist.c and
> gslist.c are really tiny, thus could easily be inlined, but aren't
> because the compiler has no access to their implementation, only to
> their prototype.

One problem I see with this is binary compatibility. The shared lib
version of glib has to provide the old non-inlined symbols, and simply
moving the functions to the header as "static inline" would remove those
symbols, even though I would not be surprised if this could be worked
around with some gcc trickery, something along the lines of:

gatomic.h:

static inline void
g_atomic_int_inc(gint *value)
{
  ...
}

ginlineimpls.c (probably auto-generated in some way):

#define g_atomic_int_inc __inline_g_atomic_int_inc
#include <gatomic.h>
#undef g_atomic_int_inc

void
g_atomic_int_inc(gint *value)
{
  __inline_g_atomic_int_inc(value);
}

Other opinions?

-- 
Bazsi