Comment 3 for bug 1324100

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.