Re: GLib plans for next cycle

[Dan Winship <danw gnome org>]

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.

https://bugzilla.gnome.org/show_bug.cgi?id=616754 has configure patches
to make building with thread support mandatory, and gobject and gio
patches to remove the !g_thread_supported() codepaths.

>  - 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.)

>  - 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.

-- Dan