Support #7142
openWStringListModel updated in slot does not work as expected
0%
Description
I have a global instance of a class DIST like:
inline std::shared_ptr d = ...
class DIST
{
..
public:
void emit(...); // emits signal message
Wt::Signalstd::string message;
};
Each session connects to this signal and tries to update a local WStringListModel:
auto local_string_list = std::make_sharedWt::WStringListModel();
d~~message.connect([=](const std::string& a_msg){ local_string_list~~>addString(a_msg); });
This WStringListModel is displayed with a WTableView. The problem is: only the session calling d~~emit(...) has the supplied message shown in the tableview. The effect in all other sessions is, only after they call d~~>emit(...) themself their WTableView gets updated to the correct number of lines, but the tableview is then stuck displaying "loading". At that point the first session also shows the the same behavior.
Updated by Roel Standaert almost 5 years ago
- Tracker changed from Bug to Support
Wt's signals are not intended to be used across web sessions, since they are not thread safe. Similarly, you can't share a WStringListModel like that between different sessions.
If you want to update other sessions, it's best to use WServer::post() or postAll() in combination with server push. You can find some example use in the broadcast example (examples/feature/broadcast), or the postall example (examples/feature/postall).
Updated by Steffen Brauer almost 5 years ago
Thank you for your answer.
Is there an overview which operations are thread-safe? Because I did a search about that topic and I could not find anything definitive in the documentation how sessions/threads are allowed to interact which each other.
Updated by Roel Standaert almost 5 years ago
Things that are thread safe are normally marked as being thread safe, or this is at least heavily implied, e.g. WServer::post(). Very few interfaces in Wt were designed to be thread safe. I think Wt follows the conventions of many frameworks in that regard, where things are only thread safe if they are documented to be thread safe.
Wt kind of creates the illusion that every session, every WApplication, is running on its own thread. That's not really the case, because it just uses a thread pool, and grabs the WApplication's UpdateLock whenever it handles an event.
Communication between sessions is regarded as something that is outside of the scope of the framework. You can leverage WServer::post() and WServer::postAll(), but you could also use thread safe data structures, locks, message passing, the database, whatever.