Wt

Consider the following basic worker thread example:

Wt::WApplication* app = wApp;
Wt::observing_ptr<Wt::WText> widget = ...; // some widget used to provide feedback
std::thread([app, widget](){
  ; // perform time-consuming task that should finish, even if the user closes its browser

  Wt::WApplication::UpdateLock lock(app);
  if (lock && widget)
    widget->setText("set some feedback ..."); // provide (intermediate) feedback to the user (finish state, error information, ...)
}).detach();

This code is not safe, as app may be already destroyed when requesting the update lock, i.e. you are accessing a dangling pointer.

The official server push example avoids accessing a dangling pointer by ensuring the worker thread finishes before the application is destroyed. However, this is inconvenient if the worker thread should continue even after the browser is closed. Using this approach may even degrade server performance by exhausting the available threads to handle incoming requests as std::thread::join blocks the current thread until the worker thread finishes (which may take quite some time if the update lock is not often requested and no other cancel mechanism is implemented). So even the server push example may benefit from a smart WApplication pointer (see further), as it would allow to detach the worker thread instead of joining it at WApplication destruction.

I'm aware that using Wt::WServer::post is often preferred over grabbing the update lock manually. Disadvantage is that extra attention is needed to avoid copying observing_ptr objects without having the update lock. Off course, this can be resolved by encapsulating the observing_ptr inside another std::shared_ptr (as is done by Wt::WServer::schedule).

Preferred interface of the solution:¶

Exposing a kind of weak_ptr for WApplication would be useful to make the example thread-safe in the following way:

weak_ptr<Wt::WApplication> app = wApp;
Wt::observing_ptr<Wt::WText> widget = ...;
std::thread([app, widget](){
  ; // perform time-consuming task

  Wt::WApplication::UpdateLock lock(app); // lock should fail if object referenced by weak_ptr is already destroyed.
  if (lock && widget)
    widget->setText("set some feedback ...");
}).detach();

Is Wt::observing_ptr<WApplication> a solution? Not without making Wt::observing_ptr thread safe¶

Note that Wt::observing_ptr<WApplication> could not be used, as this would be a chicken or the egg dilemma, i.e. update lock is needed to check whether the observing ptr is valid, but the application referenced by the observing ptr is needed to take the update lock. Enhancing observing_ptr to allow thread safe copying (just like weak_ptr) may be a solution, but this may result in an undesirable performance degradation of observing_ptr.

Work-around / possible solution: std::weak_ptr<Wt::WebSession>¶

Note that the following work-around could already be used (but it uses the internal and non-documented Wt::WebSession object):

std::weak_ptr<Wt::WebSession> session = wApp->session()->weak_from_this();
Wt::observing_ptr<Wt::WText> widget = ...;
std::thread([session, widget](){
  ; // perform time-consuming task

  std::shared_ptr<Wt::WebSession> session2 = session.lock(); // safely check whether the session is already destructed
  if (!session2)
    return;

  Wt::WApplication::UpdateLock lock(session2->app());
  if (lock && widget)
    ; // provide (intermediate) feedback to the user (finish state, error information, ...)
}).detach();

So, a solution may be to update UpdateLock to accept a std::weak_ptr<Wt::WebSession> object or a wrapper around this object to avoid exposing implementation details.