[RFC wayland 1/2] client: Introduce 'proxy wrapper' concept

[Pekka Paalanen]

On Wed, 1 Jul 2015 14:50:58 -0700
Bill Spitzak <spitzak at gmail.com> wrote:

> I would worry that there will be more things that can be done to a proxy
> besides setting it's queue and listener. So instead of adding lots of
> arguments to the get_bar wrapper, allow the proxy to be created and
> everything set up *before* the server object is created:
> 
>     bar = wl_new_bar();
>     wl_proxy_set_queue((struct wl_proxy*)bar, queue); // default queue if
> this not done
>     wl_bar_add_listener(bar, ...);
>     wl_foo_get_bar(foo, bar);
> 
> Note the last function will have to be renamed to avoid a collision in C
> but I don't have any good ideas what to name it.

FWIW, this is roughly how Wayland API originally worked. It had to be
changed, because it had a race in object id allocation and request
sending, and both sides of the IPC expect object ids to be allocated in
order.

As id allocation must happen in the same order as sending the requests,
you cannot split them, because another thread might run in between and
send another request creating another new object, which screws up the
id allocation ordering.

Why they have to be allocated in order I no longer remember, if I ever
knew.


Thanks,
pq