On Wed, 14 May 2014 19:12:20 +0100 Neil Roberts <n...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
