[RFC] Object's pre-actions

[Marek Ch]

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

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

I know I'm a pedant but I'm just trying to validate the implementation
against
what is written in documentation.

Regards
Marek Ch


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/0cfad8e4/attachment-0001.html>