On Wed, Jan 2, 2013 at 10:41 AM, Max Kellermann <m...@duempel.org> wrote:
> On 2013/01/02 16:31, Alexander Sack <pisym...@gmail.com> wrote: > > I started to remove the warnings with a lot of #if conditionals but I was > > curious if the project plans to move the base version of Glib to 2.32 > > instead of 2.16? > > > > That would at least make the changes to mpd a lot less ugly. But I am not > > sure what are the implications of such a change (regression etc.). > > No. I consider these API changes a big regression, because they add > overhead. Previously, a GMutex was just a wrapped pthread_mutex_t, > and now I have to allocate it from the heap. > > It is more likely that we will migrate to std::mutex (C++11). Since > the code base is (slowly) being migrated to C++11, the use of GLib is > fading out. Back when we started using GLib, it was a great relief, > but GLib has also caused a lot of trouble (e.g. when cross-compiling), > and some of its APIs are just horrible to deal with (e.g. GSource). > This ugly GMutex change was just the missing nail in GLib's coffin. > Thanks Max. So when you say Glib is slowly fading out, does that mean for the core logic as well? I/O, main loop thread, etc. or just thread sync primitives? Just trying to get a feel on the overall project's direction. -aps
------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612
_______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
