Stipulate objects lifetimes

[romangg]

Currently in the server remodel project it is not yet finally decided how objects lifetime should be handled. We can distinguish mostly two cases for bound wl_globals and client-side owned wl_resources.

Globals

That seems to be straight-forward. The compositor creates the base classes (i.e. Output, Compositor, etc.) and the wl_global is advertised to clients over its lifetime.

Display association

There could be one twist: We could allow Globals to set and unset their Display association.

When a Display association is unset the wl_global on this wl_display is removed and when it is set again the wl_global gets created. That is similar to the previous create() and destroy() calls and allows to use these Globals as data storage even if the wl_global should be removed for some time (for example Output's wl_global when the Output is disabled temporarily).

Doing this by setting/unsetting the Display is more generic as it allows to switch around such objects in between multiple Display instances running at the same time.

Deferred wl_global_destroy

With libwayland 1.18 the wl_global_remove call was introduced to mitigate the issue of racy wl_global destruction. That is at the moment already setup in the Wayland::Global template class with the exception of a delay timer.

Now that is not fully independent from the state of the Display. If it goes down the delayed wl_global_destroy may not be called anymore. Likely this can be solved with tracking which Globals are currently in the process of deletion in the Display class.

Client-side resources

Initial question

While bound wl_gobals are represented by wl_resources too and there are certain wl_resources that are destroyed server-side, most wl_resources are created as a response to a client request and are destroyed when the client either disconnects or calls a destroy request on them.

When the server receives such a request or is informed about the disconnect such resources become basically defunct immediately by that and the server may not call into libwayland referencing them anymore.

So the question is if the associated server-side representation of such a resource should be deleted immediately as well or if it should go over in some defunct state.

Current method on master and server-objects branch

In master branch (and KWayland) it goes over in a defunct state but will be subsequently deleted from the Qt event loop. The question is if such an interim state is needed at all.

On the server-objects branch we currently delete immediately.

In any case for exported classes the compositor needs to be informed about the client-side destroy in some way. That is done at the moment on the server-objects branch via the resourceDestroyed() signal.

So assuming the compositor listens to this signal, interacts from one thread only and reacts accordingly by dropping the object without further access can there still be use-after-free situations?

Internally in Wrapland the issue should be easily controllable. On destroy we directly inform all connected other entities about it and they must clean up (for example Seat remove a destroyed Pointer from its list of client-side pointers).

Alternative approach with defunct state and smart pointers

The alternative is to not directly destroy the wrapper objects and always check on access if the wl_resource is still alive. This could be encapsulated into the Capsule class template. But then the wrapper objects must be deleted later for what smart pointers could be used (in particular when the compositor does not reference it any longer).