GLib plans for next cycle

[Ryan Lortie <desrt desrt ca>]

I'm working on some plans for things I want to do in GLib at the start
of the next cycle.  I'd do them now, but it's getting late.

I've tried some aborted attempts at a few of these things in the past,
but they were all made complicated and ugly by one big factor: we don't
have always-on support for creating threads in libglib.

So here's my list -- both as a solicitation of feedback and as a way to
make sure I don't forget it.

 - merge libgthread into libglib

   The amount of code in libgthread is quite small and almost everything
   on earth is linking against it anyway.  Not having threading support
   built into libglib is preventing us from doing some nice things that
   we could do otherwise.

 - consider removing support for user-specified thread implementations

 - merge libgmodule into libglib

   This isn't really important, but why not?

 - glib_get_worker_context()

   Add a new function for use within glib (and gobject, gio):

      GMainContext * glib_get_worker_context (void);

   This function would create a thread (which we can do if libgthread is
   in libglib) and setup a GMainLoop running in it, returning the
   context.  Future calls would return the same context.  This gives us
   somewhere to take care of things "in the background" and gives us the
   benefit of always having a mainloop running (so we no longer have to
   go out of our way to support the non-mainloop use case of GLib).

 - remove the racy non-threaded case of GMainContext

   We currently have a long-standing race condition in GMainContext that
   occurs when dealing with signals in the single-threaded case only. 
   This is what used to make gtester randomly hang sometimes (before a
   workaround was added to gtester).  Since we have libgthread
   always-on, we can solve that problem once and for all, in addition to
   ripping out a bunch of rarely-used code.

 - make GMainContext use the GLib worker context

   GMainContext currently uses its own internal worker thread to deal
   with signals in the threaded case (which is why they're reliable). 
   It could share the worker thread.

 - make GDBus use the GLib worker context

   GDBus uses a worker thread.  It could also share.

 - make GSettings use the GLib worker context

   Here's the 3rd separate worker thread in typical GNOME programs. 
   Merge it as well.

 - make GTimeZone use the worker context

   This would allow us to detect changes in /etc/localtime via inotify
   instead of polling it each time we create a new GDateTime.

 - land some very minor (and 100% compatible) changes to the GSource API

   see https://bugzilla.gnome.org/show_bug.cgi?id=657729

 - with the updated GSource API we can start looking at epoll in a
   meaningful way


Cheers