[PATCH wayland] client: ensure thread safety for wl_display_roundtrip_queue()

[Pekka Paalanen]

On Wed, 2 Mar 2016 11:01:12 -0800
Bill Spitzak <spitzak at gmail.com> wrote:

> On Wed, Mar 2, 2016 at 4:25 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 
> >  
> > > bar_obj = wl_bar_new();
> > > wl_proxy_set_queue((wl_proxy *)bar_obj, queue);
> > > wl_bar_add_listener(bar_obj, ...);
> > > /* whatever else to init bar_obj */
> > > wl_bar_create(bar_obj, foo_obj, ...);
> > >
> > > Hopefully the wl_bar_create function will appear in the documentation  
> > where  
> > > the programmer expects, in the same page as wl_bar_destroy and all the
> > > other wl_bar_xyz methods.  
> >
> > I think you have forgot the fact, that objects in the protocol sense
> > cannot be created out of thin air. They are always created by a request
> > on an object of a *different* type. Therefore the name must be
> > wl_foo_create_bar() for wl_foo.create_bar request, not wl_bar_create()
> > which would mean a wl_bar.create request. Also the "_bar" in
> > "create_bar" is already encoded in the XML spec, so you cannot just
> > mutilate it as you want.
> >  
> 
> It's not creating it out of thin air. What I have done is rename
> wl_foo_create_barEX() to wl_bar_create()

You can add to the name, but you cannot really remove anything from the
parts of the name that come from the XML, because it will be hard to
guess what to remove.

> and swapped the arguments around
> so that the (blank) bar proxy is the first argument. The implementation is
> unchanged and sends a message to foo. A new version of marshal that can
> undo the argument rearrangement is needed however.
> 
> The purpose is to put the "constructor" into the "namespace" (in this case
> function prefix) that most programmers expect. In every language I am aware
> of, the constructors are part of the object being constructed, not part of
> an object needed to construct it.

Your namespacing is incorrect. It is not a method on class wl_bar, it is a
method on object of type wl_foo which just happens to create a new
object of type wl_bar.

For example, what would you do with wl_display.sync request which
creates a wl_callback object? It makes absolutely no sense to call
wl_display.sync as wl_callback_create().

> wl_foo_create_bar would still exist for back compatibility. Another nice
> thing about this idea is that it avoids the need for "EX" to avoid
> colliding with this function.
> 
> > This is not a manually implemented C function you can just arbitrarily
> > decide how to lay out, it must be generated from the XML description.
> >  
> 
> I believe this can be generated by wayland_scanner as it is a different
> transformation of any function that takes a newid.

Except where you remove parts of a name coming from the XML.

> It may make sense to add a new thing to the xml to declare this inside ba.
> This would allow the comments in the xml file to be in the correct place,
> and make it easier to generate the code and documentation output in the
> correct order. This command could either require a matching method on foo,
> or automatically generate it.

It is not impossible, just very awkward, to have several different
factory interfaces creating objects of a certain type. The most notable
examples are wl_buffer and wl_callback.

The documentation issue is unrelated, and it is solvable by a document
generator already, see e.g.:
https://people.collabora.com/~jonny/protocol/wl_buffer.html
listing the (known) interfaces that reference the type. It would be
easy to split that list into factories and mere references. The catch
is that the generator needs to have all XML files available at the time
to gather the information.

The link comes from
https://bugs.freedesktop.org/show_bug.cgi?id=83431


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