MirWaitHandle and client guarantees
cemil.azizoglu at canonical.com
Thu Feb 11 21:20:01 UTC 2016
We've had extensive discussions on this topic recently in a (seemingly
harmless) MP . Just wanted to compile the key points and actions that (I
think) came out of that discussion :
- MirWaitHandle could potentially give clients the (false) impression
that their request has been fulfilled, when, in fact for a number of
reasons, it may not have been (e.g. MirWaitHandle returns after IPC but the
server might still be working on it, or shell may have overridden client's
request due to policy, etc).
- We do not want a mechanism that synchronously serializes client
requests, as some requests might be slow, and others fast.
- Clients must not assume anything about the outcome of an operation
(like a state change) - they should rather listen and react to
(asynchronous) events coming from the server.
- That said, MirWaitHandle could be useful for our tests which we have
control over and can force the server to honor requests in a predictable
manner, and with no interference from a (human) user, in order to create a
certain scenario being tested.
Some actions we need to take :
- Deprecate (and eventually privatize on the next ABI break)
mir_wait_for() to prevent misuse/abuse.
- Extend use of a MirSurfaceSpec-like api to make atomic changes. For
everything else, clients should rely on an event-driven mechanism.
- Review tests to make sure that MirWaitHandles are not being
- Update documentation to emphasize what a MirWaitHandle does and how it
should not be relied upon for request sequencing by the clients.
- Perhaps we could write a simple, but nontrivial app as an example, to
drive home the key points and avoid pitfalls.
Let me know if I've skipped anything. Otherwise, I'll create a card for
Mir Display Server - Team Lead
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mir-devel