additional race in the wayland protocols?

[Eugen Friedrich]

>
> On Mon, 25 Mar 2019 22:08:38 +0100
> Eugen Friedrich <friedrix at gmail.com> wrote:
>
> > Hi Pekka,
> >
> > thanks for the replay!
>
> Hi Eugen,
>
> did you intend to cc the mailing list?
>
actually yes

> > > I would also like to see if we can forbid requests that both destroy
> > > the protocol object and create another one in one message. This would
> > > avoid the need for wl_proxy_marshal_constructor_destroy(). Marshalling
> > > is already getting a little bit combinatorial with constructor,
> > > versioned, and array.
> > >
> > this I did not get!
> > the requests are not in the same message, destroy is an request
> > and create an event in this case, also triggered by different calls:
> > wl_display_flush for sending requrest and
> > wl_display_read/dispatch* to receive the events.
> > Have nothing in mind how to prevent the race, what should be forbidden?
>
> I wasn't talking about any known existing protocol extension we know
> of. It is just that I suspect it is currently not forbidden to design a
> request that is both a destructor and has a new_id argument, so we
> should assume that someone out there is doing exactly that.
>
> If someone is doing that, wayland-scanner needs to figure out how to
> call the wl_proxy API. To make that use case race-free against
> everything else that might be going on, there would need to be a
> wl_proxy_marshal_constructor_destroy() kind of functionality. I would
> not like to have to add that, it seems too niche.
>
> If it was added, it would need versioned vs. unversioned, and array vs.
> vararags forms as well, so it would be at least four new ABI functions.
>
maybe it will be possible to forbid any arguments for type=destructor?
at least currently could not find any desctructor with arguments in
the wayland-protocols..
>
> Thanks,
> pq