[RFC] Object's pre-actions

[Pekka Paalanen]

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).

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.

> 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.

> 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?

> 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.


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
> >