Skip to content

RFC: Clean up m_resource_map after calling destroy_resource() func

Vlad Zahorodnii requested to merge work/fix-asan into master

Currently, when a resource gets destroyed, the destroy func will be called after the resource is removed from the resource map, which seems pretty reasonable!

On the other hand, if the wrapper operates in the multi-cast mode, we want m_resource to be valid when the destroy_resource() function is called to properly perform cleanup.

Another issue is that given that m_resource_map is cleaned up before calling the destroy_resource() function, the object pointer of the resource won't be cleaned up if the wrapper is destroyed inside the destroy_resource() function.

In order to make the destroy listener code more comprehensible, this change makes the generated code clean up m_resource_map after invoking the destroy_resource() function. There are a couple of reasons

  • Unify the behavior of destroy_resource() for unicast and multicast wrappers
  • It makes the resourceMap() API consistent with libwayland-server API, in particular wl_client_for_each_resource(). When the resource destroy listener is invoked, wl_client_for_each_resource() won't exclude the destroyed resource

Unfortunately, it is also an API breaking change. You cannot have code something like

void Foobar::zwp_foobar_destroy_resource(Resource *resource)
{
    if (resourceMap().isEmpty()) {
        delete this;
    }
}

Instead, you should explicitly destroy inert wrappers, which is probably a good thing.

Note: this goes against the policy that requires patches should be committed upstream first because I'm not 100% sure about the proposed change

Merge request reports