Re: GLib plans for next cycle

[Ryan Lortie <desrt desrt ca>]

hi Colin,

On Thu, 2011-09-01 at 16:13 -0400, Colin Walters wrote:
> There's a huge amount of stuff here - how much of this is really
> dependent?  Feature branches are just way easier to review than one
> big "stuff".

All of it except the source API changes is dependent on the libgthread
merge.

My intention here is to mass-land this stuff after we branch the stable
GLib and use this to start the next cycle, thus the name glib-next.  I
do expect there will be significant rebasing as things are reviewed.

> > The proposed API changes are on the branch.  I've ported the timeout
> > source (which was a net reduction in code).
> 
> In particular I'd *really* like to see this as a separate branch.

This was a separate branch, actually, but I just nuked it to reduce the
noise of all the branches I've been pushing.  I'll split it back out and
push it again.

> >
> >>  - 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. :)
> 
> Right...defer this?

I consider GLib to be fully baked for this cycle -- strictly bugfixes
only at this point.

Everything in this email and on the branch is for the start of next
cycle.

> >  - 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.
> 
> Binaries - for a specific platform, yes.  Since we know Linux/glibc
> works - and these are in fact FOSS projects that we can contribute to,
> I don't see a problem just emitting pthread calls.

It might become a problem later if we decide that we want to run a
program with debugging mutexes or something.  Consider the case,
particularly, where we do things like passing a GCond* or GMutex* across
a library barrier -- if one library was compiled hard against pthreads
and the other is using some other library (like debugging mutexes) then
we're in a substantial amount of trouble.

We'd essentially be committing to "we will always use pthreads mutexes
as GMutex* and never anything else".

Your point that glibc is a free software project is a good one though --
why not just add the debug support there?

> I think glib should move more towards having separate "normal" and
> "full on super slow debug stuff" modes, similar to how the lockdep
> stuff is a config option for Linux.

I actually think the opposite.  I'd prefer if we could enable super-slow
debug mode with an environment variable.  It would make it way easier to
get debugging information out of users who are experiencing a problem
and don't want to rebuild their system glib or their application.

That's a story for another day...

> > Another question about threads is if we should still require
> > g_thread_init() to be called.

> If you're doing it in g_main_context_default(), that seems almost
> equivalent to not requiring it =)

Almost being the key word, of course.  If people expect that the
threading system is always implicitly initialised and then some day come
across the weird case where it isn't, they'll be quite confused/annoyed.

Ideally I'd like to solve this problem by always having the thread
system ready for use without explicit initialisation.  At the end of the
day, all initialisation that we do can be done by a GOnce at the first
time that we go to use the thing that needs to be initialised.  Even on
Windows, where we may not necessarily be able to have static mutexes
without initialisation, we can one-time bootstrap ourselves using a
spinlock based on atomic integer operations provided by the native
Windows interlocked API -- and I doubt it would even come to that.

Another option is to use library load constructors to run the
initialisation we need to do.  That's certainly possible on Windows
systems and anything using GCC.  I'm not sure if it's possible to do it
in a portable way from pure C, though.

Cheers