On Tue, Mar 17, 2015 at 3:07 PM, Daniel van Vugt
<email address hidden> wrote:
> The value of this branch is more clear in the surface morphing
> prototype:
> https://code.launchpad.net/~vanvugt/mir/rename-api/+merge/252864
>
> It's not "pointless". It is /probably/ required that the client be
> told if their multi-attribute modification has happened or not. In
> the latter "not" case there is no event to wait for. So you need this
> wait-for-result, or something similar like
> wait-for-error-code-or-success.
I agree that we need something; I think that the something has to be an
event, because it has to be useful to toolkits for which blocking their
thread is unacceptable.
GTK isn't going to use wait_for_error_code_or_success unless we can
provide a guarantee that it doesn't block, so we'll either need an
event or to turn our wait-handles into something more continuationy.
On Tue, Mar 17, 2015 at 3:07 PM, Daniel van Vugt /code.launchpad .net/~vanvugt/ mir/rename- api/+merge/ 252864 error-code- or-success.
<email address hidden> wrote:
> The value of this branch is more clear in the surface morphing
> prototype:
> https:/
>
> It's not "pointless". It is /probably/ required that the client be
> told if their multi-attribute modification has happened or not. In
> the latter "not" case there is no event to wait for. So you need this
> wait-for-result, or something similar like
> wait-for-
I agree that we need something; I think that the something has to be an
event, because it has to be useful to toolkits for which blocking their
thread is unacceptable.
GTK isn't going to use wait_for_ error_code_ or_success unless we can
provide a guarantee that it doesn't block, so we'll either need an
event or to turn our wait-handles into something more continuationy.