need destroy notifies on delegates

[Allison Karlitskaya]

MirEventDelegate allows specifying a callback along with a user data pointer.

It lacks a destroy notify callback which is called on the data pointer when it is no longer needed (so that it can be freed).

[Daniel van Vugt (vanvugt)]

This sounds like you're trying to map glib/gtk architecture directly to Mir. Not sure if this request makes sense for the Mir project.

The Mir client API has no concept, and should have no concept, of what the user void* data is used for. Do you have a precise use case?

[Marco Trevisan (Treviño) (3v1n0)]

I guess this is the use case:
 - https://git.gnome.org/browse/gtk+/tree/gdk/mir/gdkmirwindowimpl.c#n166

[Allison Karlitskaya (desrt)]

It's a common idiom in almost any sort of library that allows a void* to be passed to a callback function to also take a function to clean up that void* when the callback will no longer be called.

Particularly if threads are involved, it's quite difficult to know from outside of the mir library when it will be safe to do that.

As a concrete example that hopefully helps to convince you: imagine that I want to destroy a mir surface just as an event is arriving. Let's imagine that my event handling thread is running (and my delegate has _just_ been called) but the kernel has currently scheduled my main thread for execution.

My main thread is deleting the surface and doing cleanup -- at this point I must choose either to free my data or leak it. Let's say I don't like leaks, so I free it.

Now the kernel goes back to executing the event thread and the data pointer (which was valid when the event was first dispatched) is now invalid. No amount of locking can help me here because even if I take a lock as soon as I enter my event handling function, the race could occur as the function itself is being called.

[Marco Trevisan (Treviño) (3v1n0)]

Not only...

Speaking of delegates, there are some other things that make the usage of some nice aspects of the client api not "too cool".

For example, it's not possible to cancel (or disconnect) an async request (the wait handle could probably also act for that) to avoid to get a callback to be called when the owner got destroyed (yeah, we might use sync calls, but that would not be always mandatory).

In general it's possible to define only *one* delegate per each event, and thus if you expose the MirSurface or the MirConnection (without using wrappers), a client library might break your assumptions by overriding a MirEventDelegate or mir_surface_callback or mir_display_config_callback (but this is not the only case, also the internal implementation might be over-complicated by this).

[Daniel van Vugt (vanvugt)]

I was reminded about destroy notifies recently when I had to do some glib hacking.

Although their primary purpose is to provide a kind of destructor for things that might be freed in the background and/or have no guarantee of a callback being made at all (and so might be freed in the background). A secondary purpose is to be a consistent destructor that you can't forget to call.

I don't think Mir has the same strong use case per the primary purpose in glib, but it would be somewhat harmless functionality to add. The only cost is adding yet more functions to the client API and/or client ABI breaks :(

[Michał Sawicz (saviq)]

Syncing task from Mir.