Re: GLib plans for next cycle

[Ryan Lortie <desrt desrt ca>]

An update.

On Wed, 2011-08-31 at 11:50 -0400, Ryan Lortie wrote:
> 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 created a wip/glib-next branch and started working on a lot of these
ideas.

I started by merging a couple of awesome patches from Dan that consisted
of making thread support mandatory and deleting a whole tonne of totally
pointless threads-not-initialised code from gio.

Here's the status of items from my list:

>  - merge libgthread into libglib

Seemed like a popular idea, so done.

> - consider removing support for user-specified thread implementations

I did this, but I possibly regret it.  See below for more discussion.

>  - merge libgmodule into libglib

Not done due to push-back and general pointlessness.

>  - glib_get_worker_context()

Done.

>  - remove the racy non-threaded case of GMainContext

Done.

>  - make GMainContext use the GLib worker context

Done, and I think it's okay, but it may contain a race.  It's difficult
to test, though because of a glibc bug that I think I've run into.

>  - make GDBus use the GLib worker context
>  - make GSettings use the GLib worker context
>  - make GTimeZone use the worker context

Pending.

>  - land some very minor (and 100% compatible) changes to the GSource API
> 
>    see https://bugzilla.gnome.org/show_bug.cgi?id=657729

The proposed API changes are on the branch.  I've ported the timeout
source (which was a net reduction in code).

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

Big work to be done here.  This will take a while. :)

=====

On the topic of removing support for custom thread implementations: this
simplifies things a fair bit, and would let us get rid of a lot of ugly
code in gthread.h.

In some cases it could theoretically be a performance regression to do
this, though.  Here's why:

The POSIX implementation of GMutex uses the native pthreads mutex quite
directly -- so much so that it uses the pthread functions directly as
the entries for the thread implementation vtable.  That vtable is
exposed as a public global variable and macros in gthread.h do this:

#define g_mutex_lock(mutex)     \
  if (g_thread_supported ())    \
    vtable.lock (mutex);        \
  else                          \
    (do nothing);

Because the vtable.lock function is a direct pointer to the pthreads
locking function, this has the potential to be faster than calling a
real (normal) g_mutex_lock() function that then calls pthreads.

It could be that 2 normal function calls are actually faster than
looking up the address of the vtable and doing a computed jump on a
pointer contained therein -- I haven't checked yet, but I doubt the
difference is substantial either way.

The if (g_thread_supported()) thing is a performance killer, but I think
it's not problematic for a couple of reasons.  It basically comes down
to the fact that this will hopefully be (statically) TRUE in the future,
and in some cases already is.

There are a couple of approaches we could take here (keeping in mind
that the global variable will always have to be exposed for purposes of
ABI stability, even if we change the API):

 - keep things how they are now.  This has the side effect of still
   allowing the thread implementation to be replaced (which is
   questionably useful, of course).

 - remove the hackery and use normal functions, accepting the (extremely
   small) potential performance hit

 - use defines that call the pthread functions directly when we're on
   POSIX, just like we do for the atomic ops.  This forever binds us
   to never doing anything more interesting, since we will have binaries
   out there with pthread calls directly embedded.


One thing worth noting is that there is at least one custom thread
implementation in existence: the errorchecking mutex implementation.  It
could be nice to keep that around.


Another question about threads is if we should still require
g_thread_init() to be called.  There is currently a lot of setup code
that needs to be run and I'm not sure if it's possible to get rid of it
all.  Right now, how it works on the branch is that something that needs
the thread system to be initialised will call g_thread_init_glib()
directly, which will do the work.

It might be nice to get rid of the init call entirely and just have
threads that are always working, right from the start.  That would
certainly be necessary in order to drop the g_thread_supported()
conditional.  That would require a bit more work.

Cheers