Re: GLib plans for next cycle

[Colin Walters <walters verbum org>]

On Thu, Sep 1, 2011 at 3:17 PM, Ryan Lortie <desrt desrt ca> wrote:
> 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.

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

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

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

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

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

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.

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

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