Re: gtkmm 3.0.



2010/3/26 Chris Vine <chris cvine freeserve co uk>:

> I agree that the libsigc++ model is unsound in a multi-threaded
> environment, but while gtkmm depends on libsigc++ I think it would be
> desirable to deal with the most egregious problem with it, which is
> that only one thread can safely construct slots representing ANY member
> of a class derived from sigc::trackable.

well, there's that. but there is also the fact that only thread can
manipulate a given signal's list of slots at a time, which is also
pretty egregious. not necessarily for gtkmm because it has its own
thread limitations, but for general use of sigc++ (as we used to do in
ardour) its a deal breaker.


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