On Thu, Sep 1, 2011 at 3:17 PM, Ryan Lortie <de...@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 =) _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
