Re: GThread struct now hidden



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]