Anything like GDestroyNotify in the mm api?

[Aleksander Morgado]

Hey!

>
> Now I just need to understand why even when I call mm_modem_create_bearer and immediately cancel the GCancellable, My callback is called with the error "Operation was cancelled", but the bearer is still created. This is an unrelated issue, so I can create a new email thread on this question if I can't figure it out.
>

That's easy to explain I think.

Internally, all the async operations are implemented using GTasks.
When the async operation starts, the GTask is created with the input
GCancellable associated, and (by default) that means that if the
cancellable is ever cancelled, the GTask is ALWAYS going to return a
G_IO_ERROR_CANCELLED, even if the actual async operation may have
finished successfully. So it may happen that the internal async method
finished with a g_task_return_boolean(TRUE) or similar, but the actual
g_task_propagate_boolean() called in the _finish() ends up returning a
cancelled error instead of TRUE, because the GCancellable was
cancelled meanwhile. See the docs for g_task_set_check_cancellable()
which is the method that could be used to disable the default
behavior.

Now, another thing is the rationale of when this logic should be
applied, or if it even makes sense to do that in certain operations
like mm_modem_create_bearer(). You could argue that if this method
fails with whatever reason, it must mean that the bearer object wasn't
created, and I could probably agree with you. There would be two ways
to solve this: make sure that internally the async method handles the
cancellation gracefully and so we make sure the bearer is destroyed if
it was created but the operation was cancelled; or otherwise make the
operation not cancellable at all (ignoring the input cancellable).

This is some thinking that we should put in all APIs I'm afraid; I'm
sure there are some that already can be considered safe, but lots of
others that change state or create objects probably aren't.

-- 
Aleksander
https://aleksander.es