[RFC] Object's pre-actions

Wed Nov 20 08:50:54 PST 2013

On 20 November 2013 16:40, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Wed, 20 Nov 2013 15:40:50 +0100
> Marek Ch <mchqwerty at gmail.com> wrote:
>
> > That is true, the race is there and I keep it in mind. But I'm talking
> > about the case, when the global_remove event has been already
> > dispatched (so the client should know that the global 'should' be
> > gone). In this case the object should remain valid but all requests
>
> If you assume that the global_remove event has already been dispatched,
> then the application itself has already destroyed all the objects it
> needs to destroy. Or, it has scheduled their destruction, and what
> happens with them before that is irrelevant, because the server will
> ignore any requests to them anyway. Therefore I see your proposal as
> just redundant to something everybody needs to implement in a custom
> way in any case. All you would achieve is a few hundred bytes less
> traffic through the socket.
>
> > to it should be ignored (according to documentation). But that is
> > not true atm. Consider this piece of code:
> >
> > global_remove_handler(void *data, ...)
> > {
> >     int *done = data;
> >     *done = 1;
> > }
> >
> > ....
> > int done = 0;
> > data = &done;
> > ....
> > while (!done)
> >     wl_display_dipatch(..);
> >
> > // global_remove announcement must have been dispatched here
> > // so the client knows that the global is gone
> > // now try to make request to the removed object (wl_seat)
> > struct wl_proxy *p = wl_seat_get_keyboard(seat);
> >
> > According to the documentation the return value of
> > wl_seat_get_keyboard should be NULL (or the request should be
> > ignored some other way, but what other way?).
>
> That is not what ignoring means. It means the server will ignore the
> request (and "ignore" is still a slightly wrong word, since the server
> needs to prevent fatal protocol errors here, that may arise from the
> race).
>

That is what I didn't understand correctly. I thought that the request
should be
ignored right on the client side.

Also, the C function syntax may add some confusion. It might look like
> the server is returning a new object, but that is not the case. The new
> object is created on the client side, and returned from the function.
> What happens on the wire is that the server just gets notified that
> there now is a new protocol object. The server cannot deny that.
>
> Returning NULL is not an option unless malloc() fails.
>

I know the object is created on the client side. But as I wrote - any other
way of "ignoring" the request on client side did not strike me
(check if proxy is valid -> if not then return NULL).

> > And here is no race at all. The event is gone from
> > client's buffer and what is the state of the display doesn't matter
> > because client knows that the object is gone and should ignore it
> > further. Or am I wrong?
>
> You are only pushing the race to a slightly different place. The race
> is still there when the global_remove has not yet been processed
> in the client, and all the inert object stuff has to be implemented in
> all servers. You just make the race a bit harder to hit, so I do not see
> any benefit.
>

I assumed the global_remove has been processed.

> > The problem is how to make the client ignore it. How to turn
> > the 'should' into 'have to'. And that is why I proposed the new
> > set of listeners that would be called right before the user's listener
> > and could possibly change something in client's display. In the case
> > of global deletion it could just, for example, mark the proxy as invalid
> > and any further use of the proxy would check if the proxy is valid.
> >
> > -> dispatch global_remove
> >      -> wayland-defined listener: mark proxy invalid or whatever
> >      -> user's listener: do what user needs
> >
> > So as a response for an event there could be called two methods, one
> > defined by wayland for internal stuff and one defined by user.
> > It could be used for other things too. For example if display events
> > would be handled by wayland listener then the user could define its
> > own listener for display events and could catch an error and write out
> > nice error message on his side (that's just an example!)
>
> Sorry?
>

It was just stupid example. Nothing better did strike me before.
I wouldn't define own display listener (but it would be possible,
so I used it as an example)

> > I know I'm a pedant but I'm just trying to validate the implementation
> > against
> > what is written in documentation.
>
> Sure, we probably miss the proper global_remove handling in many
> places, especially in clients, but this is not the way.
>
> I'm not sure what problem you are trying to solve.
>
> The only thing I'm trying to solve is that the wayland implementation seems
behaving a little bit differently than is asserted in documentation.
But maybe I just misunderstood it and as you wrote:
> Therefore I see your proposal as
> just redundant to something everybody needs to implement in a custom
> way in any case. All you would achieve is a few hundred bytes less
> traffic through the socket.
I admit the proposal wouldn't bring much.
Thank you for your time and patient answers :)

Thanks,
Marek Ch

> Thanks,
> pq
>
> > On 18 November 2013 18:49, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> >
> > > On Mon, 18 Nov 2013 16:54:03 +0100
> > > Marek Ch <mchqwerty at gmail.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > in reaction to
> > > >
> > >
> http://lists.freedesktop.org/archives/wayland-devel/2013-November/012018.html
> > > > I have got an idea and I like to share it with you and possibly get a
> > > > feedback.
> > > >
> > > > What I was thinking about is:
> > > > Add into wl_object another variable for listener (implementation)
> that
> > > > would be set
> > > > when proxy is created (or set to NULL when not needed). In this new
> > > > listener would be actions that should be done in display (client's
> > > display)
> > > > before actual dispatching the event. Example with the global
> deletion:
> > > >
> > > > client recieves global_delete event and in dispatching phase there
> would
> > > > these steps:
> > > > preaction_global_delete(..)                       // this is new
> > > > {   mark proxy id as invalid  or whatever }   //   ..............
> > > > user_global_delete(..)                              // this is what
> is
> > > now
> > > > {  anything user wants ... }                       //
>  .............
> > > >
> > > > So, basically, the result would be triggering an action defined by
> > > display
> > > > (but on client side) on particular event coming.
> > > >
> > > > Is it any way useful (I can imagine it work for example for the
> global
> > > > deletion) or is it just silly idea?
> > >
> > > Hi Marek,
> > >
> > > I'm not sure I understand what you propose here, but whatever you
> > > do client-side will not remove the race, and the race is what
> > > requires compositors to turn objects inert instead of just destroying
> > > their protocol bookkeeping.
> > >
> > > The compositor may delete a global, and send the deletion events,
> > > but the events could be sitting in the compositor's send buffer,
> > > socket's buffers, or the client's receive buffer while the client
> > > is happily sending new requests on the deleted objects and not even
> > > looking at the incoming events.
> > >
> > > In fact, the client could be sending the requests even before the
> > > compositor decides to the delete global object, and the requests
> > > could already be sitting in any of the message buffers while
> > > compositor decides the global is now gone.
> > >
> > > We do need the wl_resource objects alive (but inert) in the server
> > > until the client is guaranteed to know that the protocol object is
> > > no more. Destroy request is the standard signal for that.
> > >
> > >
> > > Thanks,
> > > pq
> > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20131120/773e4c33/attachment.html>