[PATCH wayland] server: add helper functions for wl_global

[Daniel Stone]

Hi,

On 9 March 2015 at 07:49, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Mon, 23 Feb 2015 17:20:37 -0800
> Bryce Harrington <bryce at osg.samsung.com> wrote:
>> However, I suspect this API would be better named as
>> wl_global_find_first().
>>
>> A more general wl_global_find() I would expect to be returning a list of
>> results.
>>
>> One thing to think about when writing a test case, is if this function
>> will always return the same first result.  E.g. if the globals list
>> depends at all on timing of hardware bringup thight might vary boot to
>> boot, or if hashes are in any way involved in creating it, or etc.
>> I'm guessing that's not the case, but probably worth checking, else
>> we'll inevitably have a bug reported about it on some obscure piece of
>> hardware.
>
> I'm certainly in favour of making this "find" API to return *all*
> matches, not just a random match like it is now. Then, if the caller
> expects to ever find either 0 or 1 globals, it can yell if that
> invariant is ever broken.

Yes, agreed.

> But, I also cannot really see why the underlying problem could not be
> solved completely inside the libEGL implementation.
>
> If one is looking for an existing wl_drm global, you already assume it
> has been created by *this* particular libEGL where you are currently
> executing. Therefore, this loaded libEGL.so could maintain
> library-global state where it lists the wl_drm globals it has created
> and for which wl_display.
>
> But, I also imagine that might be more complicated to realize than
> using a find-API, so the idea of the find API is ok by me.

It _could_ be, given adequate though to locking, and also static
initialisation for the locks.

> I would just want it to return all hits. That way you don't even need
> to special-case the no-parameters case and you just trivially return
> all globals.
>
> Btw. just to be annoying... ;-)
> Does EGL spec say anything about multi-threaded calls into the EGL API?

Not in this case (eglBindWaylandDisplayWL).

> How do you know which lock protects the libEGL's globals? Is there only
> one global lock for everything that would guarantee the list returned
> by the find-API won't become out-of-date?

There is no particular guarantee; it would be entirely possible to hit
a race and lose. But that's EGL for you, and already bites in multiple
places today.

Cheers,
Daniel

> Thanks,
> pq
>
>
>> > On 02/23/2015 10:06 AM, Jonny Lamb wrote:
>> >
>> > >+/** Find a wl_global given search parameters
>> > >+ *
>> > >+ * \param display The display object
>> > >+ * \param interface The interface to match, or NULL
>> > >+ * \param version The version to match, or 0
>> > >+ * \param data The user data to match, or NULL
>> > >+ * \param bind The function used to bind the object, or NULL
>> > >+ * \return The first wl_global which matches, or NULL
>> > >+ *
>> > >+ * The global list of a wl_display is not public so this function helps in
>> > >+ * finding a specific wl_global based on the parameters. Parameters can be
>> > >+ * missing for a broader search (NULL for interface, data, and bind, and 0 for
>> > >+ * version) but at least one must be present or no result will be returned.
>> > >+ *
>> > >+ * \memberof wl_global
>> > >+ */
>> > >+WL_EXPORT struct wl_global *
>> > >+wl_global_find(struct wl_display *display,
>> > >+  const struct wl_interface *interface, uint32_t version,
>> > >+  void *data, wl_global_bind_func_t bind)
>> > _______________________________________________
>> > wayland-devel mailing list
>> > wayland-devel at lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel