[RFC wayland] Add wl_proxy destruction callbacks

[Jonas Ådahl]

On Tue, Jun 07, 2016 at 10:42:11AM +0200, Miguel Angel Vico wrote:
> Hi,
> 
> Sorry for the slow response. Inline.
> 
> On Tue, 31 May 2016 11:18:25 +0300
> Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 
> > * PGP Signed by an unknown key
> > 
> > On Mon, 30 May 2016 13:10:42 +0200
> > Miguel Angel Vico <mvicomoya at nvidia.com> wrote:
> > 
> > > Hi all,
> > > 
> > > A few days ago, I had a little chat over IRC with Pekka about
> > > addition of proxy objects destruction callbacks to the wayland
> > > client protocol.
> > > 
> > > 
> > > Summing up, we recently ran into some applications where native
> > > objects (wl_surface, wl_egl_window, wl_display) used by EGL are
> > > destroyed/made invalid before destroying the corresponding EGL
> > > objects. This sometimes causes crashes of the EGL driver, which is
> > > not nice. We have seen this with the NVIDIA EGL implementation, but
> > > I assume the Mesa EGL implementation is similarly exposed.
> > > 
> > > I agree this is in fact an application bug, but the EGL spec states
> > > that functions such as makeCurrent or swapBuffers should return
> > > error (not crash) if the native objects become invalid. I also
> > > agree the spec should have been clearer and probably allowed
> > > "undefined behavior", but it is not the case.
> > > 
> > > Having an objects destruction notification mechanism such as
> > > destruction callbacks would allow us to satisfy the spec.
> > > 
> > > Also, such functionality would also make life way easier under
> > > certain circumstances. I'm basically thinking about multi-threaded
> > > applications, where several threads make use of the same native
> > > objects, and for some reason one of the threads has to destroy one
> > > or more of them due to some sort of error happening.
> > > 
> > > Of course, this can still be considered an application bug, and the
> > > application could still make sure none of the threads is going to
> > > use the native objects before destroying them, but again, specs
> > > allow users to do many non-recommended things.
> > > 
> > > I think we should try to do our best to gracefully handle those
> > > non-desirable API usages, and avoid crashes whenever is possible.
> > > 
> > > 
> > > Pekka did not see this as something crazy to have, but wanted to
> > > hear from some of the toolkits guys before making the decision of
> > > whether changing the wl_proxy ABI is a good idea.  
> > 
> 

... snip ...

> > 
> > > 
> > > As an alternative, destruction callbacks could be hung off of
> > > wl_egl_window. In a similar way we support wl_egl_window_resize
> > > callbacks, we could support wl_egl_window_destroy callbacks.  
> > 
> > At the moment I would slightly favour the wl_egl_window approach if it
> > allows to circumvent the EGL wording and the wording cannot be fixed.
> 
> If no one else is interested in adding wl_proxy destruction callbacks,
> I'll just go with this alternative and send an appropriate request for
> review so it can be integrated in Mesa drivers as well. I wouldn't like
> this to be a NVIDIA-specific feature.

For what it's worth, from a toolkit point of view, I've never had the
need for any wl_proxy destruction callbacks, as I've always been the one
who owned them to begin with. If anything, I've had destruction
callbacks on the higher level objects that themself own the wl_proxy.

In other words, I think adding destruction callbacks to wl_proxy should
be avoided if we can't solve a given problem any better way.


Jonas

> 
> > 
> > > However, this isn't as foolproof as adding wl_proxy destruction
> > > callbacks, since destruction of wl_surface or wl_display objects
> > > before wl_egl_window would lead to same issues.
> > > 
> > > 
> > > I really think adding destruction callbacks to wl_proxy would be an
> > > improvement worth making, but others' thoughts must be heard
> > > first.  
> > 
> > 
> > Thanks,
> > pq
> > 
> > * Unknown Key
> > * 0x11AAAAA7
> 
> Thanks,
> 
> -- 
> Miguel
> 
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel