Re: GLib plans for next cycle



On Wed, 2011-08-31 at 12:52 -0400, Dan Winship wrote:
> On 08/31/2011 11:50 AM, Ryan Lortie wrote:
> >  - merge libgthread into libglib
> 
> Getting rid of libgthread or moving any of its symbols into libglib is
> an ABI break on some platforms.
> 
> Of course, since there are only 2 exported symbols (g_thread_init and
> g_thread_init_with_errorcheck_mutexes), I guess you can just move
> everything else in libgthread into libglib, and keep libgthread with
> those methods as no-ops.

My exact plan is to leave the library installed with the two functions
calling equivalent functions in libglib (or doing nothing at all if we
decide to scrap user-provided thread implementations as well).

Next step is to modify the libgthread.pc file so that newly-compiled
programs don't even bother linking the library anymore.

We could also use the symlinking trick -- make libgthread a symlink to
libglib, thus maintaining compatibility.  There was a lot of talk about
how this is a valid technique when we were considering the
libgobject/libgio merges.

> >  - merge libgmodule into libglib
> >
> >    This isn't really important, but why not?
> 
> Well, the same ABI issues again. If you don't have a use case it might
> be better to not bother. (Or, you could rename it in glib. Or have it as
> a private API in glib, with libgmodule just having public API wrapping it.)

Since I don't have a compelling case for it, it might indeed be best to
just leave well enough alone.

> >  - glib_get_worker_context()
> 
> s/glib/g/ ? glib_* sounds like it's for glib-internal-only use, which I
> don't see any reason for. It's definitely useful outside of glib.

My original intention is that it *would* be glib-private (like
glib_gettext() for example).  It's true that other libraries could find
it useful, though -- dconf would certainly put itself on this list.  I'm
just slightly worried about this thread becoming contaminated (think:
mainloop blocking) through use by poorly written libraries.

Cheers



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]