Feature #2542
openServerSignal utility
60%
Description
I'm currently working on a ServerSignal utility class which has a similar but somewhat limited interface as boost::signals. The main purpose is so that I wouldn't have to create containers to hold session data every time I want an inter session communication. Currently it does work but has missing features and I'm still working on it.
It is to features the following
- Uses WServer::post()
- Uses read/write thread locking in the ServerSignal utiltiy
- Creates trackable connection with WObject
- Allows 2 kinds of emit functions, one with arguments as specified by template arguments, one without argumens(a hacky version currently implemented)
- Allows up-to 6 arguments as Wt::Signal(Only using 2 specialized classes during testing, will add the rest when every thing is complete)
- Gives information about sender(WServer*, WApplication* should be implemented with WServer::post())
-
Uses WApplication::bind()(should it be used internally or externally?)
TODO
- Make connection trackable with WObject
- Use a different method to accept 0 argument boost::bind(Can't be overloaded, can't be template generalized because boost's bind_t doesn't implicitly convert to boost::function when signature is generalized)
- Create a way to get sender WApplication pointer when ServerSignal is emitted
I posted this because I'm new to function objects and template programming. If Wt team is interested, it may reimplement this in any way.
Forked branch for ServerSignal: https://github.com/SaiFi0102/wt/tree/ServerSignal
Commits: https://github.com/SaiFi0102/wt/commits/ServerSignal
Updated by Saif Rehman over 10 years ago
I'm curious if a simple connection with WApplication::bind() and disconnection at WObject's destructor would be safe or would a tracking technique like boost::signals2 have to be implemented? Not exactly sure how WApplication::bind() works.