Rethinking MirWaitHandle

[Daniel van Vugt]

You know it's a feature of MirWaitHandle that multiple threads can and 
do wait on the same handle? We rely on this feature; I forget where.

But that means your actual wait call can't free the wait object. More 
wait calls can and will come along and use it later (from different 
threads even).


On 13/03/14 09:50, Christopher James Halse Rogers wrote:
> Hey all!
>
> While wandering through the various latent valgrind errors that
> udevify-eventhub somehow exposes I noticed that we have an open TODO to
> work out what the lifecycle of MirWaitHandles should be.
>
> Thinking about it, in the new context of our plan to finish moving
> error-handling into error-objects we could rework the API so that our
> creation calls immediately return an object in an invalid state, plus an
> explicit syncpoint call.
>
> Something like:
>
> ============
> MirSurface surf = mir_surface_create(connection)
> if (!mir_surface_is_valid(surf)) {
>     std::cout<<"Barring strange scheduling, we'll always get
> here"<<std::endl;
> }
> MirSyncPoint sync = mir_request_sync_point(surf);
> mir_sync_point_wait(sync);
> // mir_surface_is_valid is now true. Or false, if a server error occurred
>
> //...
> mir_surface_swap_buffers(surf);
> MirSyncPoint sync = mir_request_sync_point(surf);
> mir_sync_point_callback(sync, called_back_once_swapbuffers_is_done, ctx);
> //...
> ============
>
> This would clean up our API a little, and since MirSyncPoints are always
> explicitly requested their lifetime can be terminated by
> mir_sync_point_wait().
>
> Just a thought while waking up this morning...
>
>