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

[Pekka Paalanen]

On Tue, 14 Jul 2015 11:02:51 -0700
Bill Spitzak <spitzak at gmail.com> wrote:

> On Tue, Jul 14, 2015 at 6:26 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 
> >
> > >     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.
> >
> 
> My guess is they don't really have to be in order, but that it was
> desirable to avoid the overhead of two locks (one for allocating an
> objectId and a second for the wl_connection_write), by using one lock
> around them all.

I recall as much to say that your guess is wrong. It's about keeping the
two maps in the different processes in sync, not about locking. Git
archeology could reveal details.

> I would think a wl_proxy could exist without an objectId allocated. Then
> you could allocate the id right next to the wl_connection_write in
> wl_closure_send, and the lock is only around these two statements. This
> would make a much smaller piece of code single-threaded, it would also
> preserve the objectid allocation and message order if that really is
> necessary, and still only use one lock. And it would allow the wl_proxy to
> be created and modified before it is assigned to an actual object.
> 
> This would require wl_closure_send to understand newid arguments, just like
> it is special-casing fd arguments.

I can't dismiss the idea of delayed object id allocation off-hand,
might be worth investigating if it could work without breaking anything.


Thanks,
pq