Subject: Rethinking MirWaitHandle

From: Christopher James Halse Rogers <[email-masked]>
Date: Thu, 13 Mar 2014 01:58:57 +0008

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

---

From: Daniel van Vugt <[email-masked]>
Date: Thu, 13 Mar 2014 09:54:59 +0800

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:
> creation calls immediately return an object in an invalid state, plus an
> explicit syncpoint call.
>
> Something like:
>
> ============
> // mir_surface_is_valid is now true. Or false, if a server error occurred
>
> //...
> 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().
>

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Thu, 13 Mar 2014 02:08:58 +0008

On Thu, Mar 13, 2014 at 9:54 AM, Daniel van Vugt 
<[email-masked]> wrote:
> 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.
> 

That seems like a mis-feature of MirWaitHandle, really. If people want 
to do cross-thread synchronisation they should probably use thread 
synchronisation primitives rather than rely on MirWaitHandle doing 
double duty.

---

From: Daniel van Vugt <[email-masked]>
Date: Thu, 13 Mar 2014 10:10:49 +0800

Yes, it's totally a mis-feature of MirWaitHandle but one we need right 
now. I think it might be that way because single-threaded clients 
actually are not single threaded (bug 1194384).

I don't think we should be asking single threaded clients to use 
explicit cross-thread synchronization. I think we should solve bug 
1194384 first.