[RFC 1/2] server: add wl_guard and convert one user

[Pekka Paalanen]

On Tue, 6 Mar 2012 03:43:47 +0000
Rob Bradford <rob at robster.org.uk> wrote:

> On 2 March 2012 12:10, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > From: Pekka Paalanen <ppaalanen at gmail.com>
> >
> > In wayland and weston code bases we have roughly a dozen destroy
> > listeners whose only job is to set a pointer to NULL, if a wl_resource
> > object gets destroyed.
> >
> > Introduce struct wl_guard as a shorthand for replacing all these trivial
> > callbacks.
> 
> Pekka,
> 
> This is a good thing to have - any background on your choice of
> terminology? glib calls this a "weak pointer" -
> http://developer.gnome.org/gobject/stable/gobject-The-Base-Object-Type.html#g-object-add-weak-pointer
> 
> Cheerio,
> 
> Rob
> 
> PS: The reason I ask is for me "guard" is more like something like
> g_return_if_fail etc.

Hi Rob,

Krh didn't like the name "weak pointer" too much, since this is not
a generic weak pointer. Though, he didn't like the name wl_guard that
much either, since he would want "resource" be part of the name. :-)
It is resource specific, after all.

Because I wanted to preserve type safety with wl_guard, the actual
pointer is outside of struct wl_guard, and wl_guard has that extra
pointer to the pointer. Because of this, I would not call wl_guard a
"pointer", because it does not contain the pointer. It's just some sort
of protector.

Doing ugly hacks like:

struct wl_guard {
	struct wl_listener listener;
	void *pointer[0];
};

and then requiring to always have the real pointer right after guard,
e.g.:

struct myfoo {
	...

	struct wl_guard surface_guard;
	struct weston_surface *surface;

	...
};

has crossed my mind, but it's ugly, and I don't know if there are
(alignment induced) failure cases. This hack would avoid the extra
pointer and make the guard API one parameter simpler.

Would be really cool to be able to write something like
	obj->surface = guard_set(&obj->surface_guard, surface,
				 &surface->resource);
except that one definitely loses type safety. Krh also mentioned an
idea of generating typesafe wrappers for this stuff.

struct wl_resource_protector and then wl_resource_protector_foo() APIs
seem a bit long, but I don't know... and if we make then type-specific,
even longer.

Better ideas and names welcome :-)


Thanks,
pq