Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace boost::signals2 with C++11 implementation #619

Closed
richardeakin opened this issue Nov 28, 2014 · 3 comments
Closed

Replace boost::signals2 with C++11 implementation #619

richardeakin opened this issue Nov 28, 2014 · 3 comments
Labels
Milestone

Comments

@richardeakin
Copy link
Collaborator

boost::signals2 is probably our largest dependancy on boost (other than filesystem and asio, which are both proposed for standardization), and it is also quite beefy in the realm of signals / slots implementations. Swapping it out is a breaking change, although only minor, in that method and class names will slightly change (ex. ci::signals::signal -> ci::signals::Signal).

Right now the favorite replacement candidate is a modified version of SimpleSignal, modifed in the sense that we still need to make up for a couple features. Specifically it doesn't support connections or scoped connections, and I'm not sure if its 'collector' notion equates to boost::signal2's 'combiner' notion. I have been using a modified version of SimpleSignal in private for some months now, and plan to implement these features before we make the switch.

Important: boost::signals2 is thread safe, SimpleSignal is not. This is not a problem for any of cinder's internal usage of signals, and for the most part signals are used from UI threads so it isn't a problem there either. However, if it is a problem for someone else, first please reconsider your design :), then let's discuss if this is actually a requirement for a ci::Signal implementation. Most likely, we would recommend that you keep using boost::signals2 directly, but we do want to know of any use cases that users could have and we don't know about.

Related to #611
Depends on #618 being accepted.

@richardeakin richardeakin added this to the 0.9.0 milestone Nov 28, 2014
@notlion
Copy link
Contributor

notlion commented Dec 4, 2014

I'm already using SimpleSignal since it's included with the ECS library entityx, so switching to that specifically sounds nice to me. I don't need the thread safety and such that boost::signals2 provides.

The choice to use the more minimal / performant implementation of a feature seems like a good one, since we can always upgrade to something with more features for specific use cases.

The lack of connections seems to be the most glaring omission from SimpleSignal. That's the only thing I would miss. I've personally never used scoped connections.

@meshula
Copy link

meshula commented Dec 4, 2014

I like to refer to libcaf for this sort of thing, but I'm after cross-thread and cross-process stuff. https://github.com/actor-framework/actor-framework

entityx is cool, but I didn't realize that SimpleSignal isn't thread safe.

This was referenced Feb 14, 2015
@richardeakin
Copy link
Collaborator Author

Fixed in app_refactor branch, #710

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants