[PATCH wayland-protocols v2] Add zwp_linux_explicit_synchronization_v1

[Pekka Paalanen]

On Mon, 15 Oct 2018 17:16:59 +0300
Alexandros Frantzis <alexandros.frantzis at collabora.com> wrote:

> On Fri, Oct 12, 2018 at 03:24:30PM +0300, Pekka Paalanen wrote:
> > Hi,
> > 
> > this is a good specification, all my comments are clarifications or
> > minor adjustments. The fundamental design looks fine to me.  
> 
> Hi Pekka,
> 
> thanks for the review! My answers are inline. I have sent a updated
> version (v3) of this proposal based on this discussion.
> 
> > On Tue,  9 Oct 2018 18:11:22 +0300
> > Alexandros Frantzis <alexandros.frantzis at collabora.com> wrote:
> >   
> > > Signed-off-by: Alexandros Frantzis <alexandros.frantzis at collabora.com>

...

> > > +  <interface name="zwp_buffer_release_v1" version="1">
> > > +    <description summary="buffer release explicit synchronization">
> > > +      This object is instantiated in response to a
> > > +      zwp_surface_synchronization_v1 request.
> > > +
> > > +      It provides an alternative to wl_buffer.release events, providing
> > > +      a unique release from a single wl_surface.commit request. The release
> > > +      event also supports explicit synchronization, providing a fence FD
> > > +      where relevant for the client to synchronize against before reusing
> > > +      the buffer.
> > > +
> > > +      Exactly one event, either a fenced_release or an immediate_release,
> > > +      will be emitted for each wl_surface.commit request.
> > > +
> > > +      This event does not replace wl_buffer.release events; servers are still
> > > +      required to send those events.  
> > 
> > Ok. The introduction lead me to believe otherwise, that should probably
> > be worded differently.  
> 
> I have remove all mention of wl_buffer.release from the intro.
> 
> > > +    </description>
> > > +
> > > +    <request name="destroy" type="destructor">
> > > +      <description summary="destroy buffer release synchronization object">
> > > +        Destroy this buffer release explicit synchronization object. The object
> > > +        may be destroyed at any time.
> > > +      </description>  
> > 
> > Is it inconceivable to ever add other requests in this interface?  
> 
> I don't expect other requests to be added, this is meant as
> an event-only interface.
> 
> > Could there ever be a benefit from destroying this object before it has
> > sent an event?  
> 
> The main scenario is an early exit from some code using this
> object, in which case it will be easier to correctly synchronize proper
> destruction of any user data used by the zwp_buffer_release_v1 listener,
> when having an explicit destroy request.
> 
> This isn't particular to this protocol though, it's a general
> (theoretical) concern of mine with the destroy-on-event pattern.  But if
> this has worked well for wp_presentation_feedback, perhaps it's not a big
> deal.

Hi Alf,

I'm not sure what you mean with that concern.

When an event destroys a protocol object, the compositor will
unconditionally destroy the wl_resource right after sending the event.
That means the server-side request listener cannot receive any messages
anymore, so any user data would be destroyed at the same time anyway.

On client side, regardless of whether there is destroy request or not,
the client will destroy the wl_proxy. The request would only let the
compositor know that the protocol object is no more. Regardless of a
destroy request, the client side will automatically ignore any events
to the destroyed wl_proxy. That ignoring is what makes client initiated
object destruction safe in the first place.

When the client destroys the wl_proxy, it can also free any user data
associated with it, because that will guarantee that the listeners
cannot be called anymore.

If we have a destructor event, and the client destroys the wl_proxy
before that event is sent, then the event will simply be ignored. Once
the compositor sends the event, then both client and compositor again
agree that the protocol object no longer exists.

wl_display has a "secret" event that tells libwayland-client when the
server has destroyed the protocol object, which makes all the above
work.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20181031/d6b2fc67/attachment.sig>