Wt

Wt normally handles events for a single session sequentially. Hence, normal event handling code should not be thread safe.

However, Wt::WApplication::notify may be called concurrently on a single object if private Wt::WResources are used.

It may be useful to better document that reimplementations of Wt::WApplication::notify should be thread safe.

Especially if one wants to free resources used during the request, as suggested in the example mentioned in the documentation of this member function, one should take care that those resources are freed in a thread safe way. This may not be clear based on the documentation and the provided example.

One may even wonder why events for a (private) Wt::WResource that doesn't take the update lock (i.e. Wt::WResource::setTakesUpdateLock(false)), are propagated through Wt::WApplication::notify:

• Catching exceptions is not possible, as they are already catched by WResource::handle without rethrowing.
• Grabbing and freeing resources is probably better/easier handled by the Wt::WResource itself.
• Advantage would be that Wt::WApplication::notify is not called concurrently for the same object, as is also the case for the other virtual members. This makes the (re)implementation less error prone.