Wt

Hi Michele,

this is certainly possible, and you are close to a working example!
There is only a single thing missing here.

When a signal is listened to, there is no guarantee that the connected function is executed in the same thread as the UI thread, that manages all the W... objects.
So there are two things you need to do.

1. You need to make the client side of Wt aware that the server is allowed to "force-push" information to it with WApplciation::enableUpdates().
2. The listening side (of the connection, meaning another WApplication instance) needs to ensure that the UI updates happen in the UI thread. You can do this by taking the WApplication::UpdateLock, performing ths UI changes, and then triggering the updates to the client side with WApplciation::triggerUpdate().

So, I would change:

public:
    MyApplication(const Wt::WEnvironment& env)
      : Wt::WApplication(env)
    {
        enableUpdates(true);

And also:

globalStateChanged.connect([this, slider](int state) {
    Wt::WApplication::UpdateLock lock(this);
    if (lock) {
        slider->setValue(state);
        triggerUpdate();
    }
}

I believe that leads you to a working concept.

P.S. as the documentation of WApplciation::UpdateLock indicates, you may wish to look at WServer::port().

Best,
Matthias

Hello Matthias, thank you very much for your prompt reply!
I indeed forgot to take care the UpdateLock... I didn't think about it, because I wasn't starting any background thread on my own like I sometimes do.
Adding that does the trick :-)

I have a doubt about the thread-safety of Wt::Signal::emit() and Wt::Signal::connect(), though. I'm in a scenario where several threads can use both of these methods for a given signal at the same time:

• I have an std::thread running in the background, calling Wt::Signal::emit() whenever my state is updated
• then there are the Wt sessions using Wt::Signal::connect() to receive the signal and update their view
• and finally, the same Wt sessions also use Wt::Signal::emit() whenever the user changes something in the UI, so that the other sessions can update their view based on the new state

Do I need to set up some protection mechanism in order to avoid race conditions?

Hello Michele,

that will indeed be necessary. Since all threads can modify the value, its state ought to be consistent. You'll have to mutex the variable in this design.

Best,
Matthias