Rethinking MirWaitHandle

[Christopher James Halse Rogers]

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...