additional race in the wayland protocols?

[Pekka Paalanen]

On Tue, 26 Mar 2019 22:05:28 +0100
Eugen Friedrich <friedrix at gmail.com> wrote:

> >
> > On Mon, 25 Mar 2019 22:08:38 +0100
> > Eugen Friedrich <friedrix at gmail.com> wrote:
> >  

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

Arguments in destructors are not problematic per se, it's only the
new_id arguments.

If we went for forbidding either, first would need to check how
wayland-scanner handles the case right now. If it is obviously not
working, then we can just make it more explicit and intentional with
nothing to worry about. If it looks like it may work, then we need a
deprecation period with wayland-scanner warning or failing on it to see
if anyone was actually using it. We also need a backup plan in case we
notice it is something people use and we cannot forbid.

There are lots of extensions outside of wayland-protocols, a lot more
than in wayland-protocols.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190327/b7d0e10e/attachment.sig>