Feature #2542

ServerSignal utility

Added by Saif Rehman over 8 years ago. Updated over 8 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


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?)


  • 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:



Updated by Saif Rehman over 8 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.

Also available in: Atom PDF