[PATCH] Destroy resources when destroying input and output

[Pekka Paalanen]

On Wed, 14 May 2014 19:12:20 +0100
Neil Roberts <neil at linux.intel.com> wrote:

> After looking at it a bit more I don't think we can really make
> the automatic zombie idea work. The trouble is that
> libwayland-server would need to know when the client has
> destroyed the proxy in order to destroy the zombie resource.
> However the destroy semantics are interface-dependent so only an
> implementation of the interface can know when the resource is
> really destroyed.
> 
> The wl_output interface doesn't currently have a destructor so in
> this particular case it's even worse. I guess if a client binds
> to an output then the resource for it has to leak until the
> client disconnects.
> 
> Assuming we later add a release request to wl_output (I think we
> should) then I think we would still need to make the zombie
> handling specific to the output implementation in Weston. We
> can't just set the implementation to NULL because then nothing
> would destroy the resource when the release request is called.

I think you are totally right.

> Perhaps the best thing to do would be to make Weston swap out the
> interface for a simple one that only waits for the release event
> when an output is unplugged. We would also have to do this for
> pointers, keyboards and touch devices. This could end up with
> quite a lot of code because you have to double up all of the
> implementations. We also have to be aware of these zombie objects
> if we ever add any more requests that can refer to these objects
> because they would have to check if the object is a zombie and
> skip the request.

Right.

> If there's ever a Wayland 2.0 I think it would be good to make all
> interfaces implicitly have a destructor which is handled outside
> of the protocol description. I can't think of an interface that
> shouldn't have a destructor. Even with wl_callback which is
> defined to be destroyed when it is signalled it might make sense
> to allow the client to destroy the callback early if it's no
> longer interested.

Yeah, I think there are ways to make it work, if we could change
it. Another idea would be to annotate destructors and allow both
requests and events to be destructors.

I think I have suggested this before, but we could start collecting
a Wayland protocol extension designer's cook book: rules of thumb
(e.g. always define destructor protocol unless it is explicitly not
right), design patterns (inert objects, factory interfaces...),
where and how to define errors etc.


Thanks,
pq