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
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
