On Tue, 14 Jul 2015 11:02:51 -0700 Bill Spitzak <spit...@gmail.com> wrote:
> On Tue, Jul 14, 2015 at 6:26 AM, Pekka Paalanen <ppaala...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel