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. 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. 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. Regards, - Neil _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel