On Thu, 2011-10-13 at 12:48 +0200, Murray Cumming wrote: > This change in glib master does indeed break glibmm: > http://git.gnome.org/browse/glib/commit/?id=d904612100120d12126f1a6623a106d8a5b02fa6 > Unless it's really really necessary, it would be great if you would not > do this, or if you could leave it until a glib ABI break. > > Glib::Thread has a static (but private) GThread member instance: > http://git.gnome.org/browse/glibmm/tree/glib/src/thread.hg#n285 > so obviously glibmm no longer builds. > > We do this so you can cast a Glib::Thread* directly to a GThread*. We > probably did this (in 2002?) because we have no way to associate our C++ > instance with the C instance, because GThread is not a GObject. I doubt > that we can find a way around that, though I have not tried. > > We also access the struct fields (joinable, priority) directly in simple > getter methods, but I don't know if anybody really uses them. We might > get away with breaking their functionality if we can't find > replacements: > http://git.gnome.org/browse/glibmm/tree/glib/src/thread.ccg#n120 > http://git.gnome.org/browse/glibmm/tree/glib/src/thread.ccg#n135 > At the least, we should probably deprecate those methods. > > I have no objection to deprecating our entire Glib::Thread API, if we > can replace it with a more-correct Glib::Thread2 API, but we'll be in > trouble if user applications (built with glibmm <= 2.30) start crashing > just because the user installed glibmm 2.32.
By the way, I also noticed that g_thread_init() is deprecated, presumably because you must now used g_thread_new(), so you don't need it, but I don't see a deprecation comment on g_thread_init(). -- Murray Cumming murrayc@murrayc com www.murrayc.com www.openismus.com _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list