Porting to GTask: pointer to self in context?

Ben Chan benchan at chromium.org
Thu Apr 6 18:23:28 UTC 2017


On Thu, Apr 6, 2017 at 11:09 AM, Aleksander Morgado
<aleksander at aleksander.es> wrote:
> Hey Ben, Dan and everyone else,
>
> Related to the ports to GTask sent by Ben...
>
> When using the GSimpleAsyncResult logic, I usually always added a full
> reference to the "source object" of the async operation in the
> "Context" struct, so that I could use it directly, e.g. ctx->self.
> This was really not necessary, because the GSimpleAsyncResult hold
> itself a reference to the "source object", but it was handy because I
> could use the object right away without needing to call
> g_async_result_get_source_object(), which returns a full reference
> (and therefore then I would have needed to unref that one
> explicitly...)
>
> When using GTask, though, we have  g_task_get_source_object(), which
> doesn't return a full reference.  So, in the GTask implementations
> I've done I've tried to avoid having a full "self" reference in the
> Contexts set as GTask data, and instead I would just pass around the
> GTask in the different callbacks and then just create local variables
> whenever needed like this:
>
> Context *ctx;
> MMSomeObject *self;
>
> ctx = g_task_get_task_data (task);
> self = g_task_get_source_object (task);
>
> Question being, should we still keep the "self" pointer in the Context
> struct as we did with GSimpleAsyncResult, or default to just using
> g_task_get_source_object() when/where needed?
>
> What does everyone think?

Yep, I noticed that as well and though the self reference isn't
necessary. During my porting, I remove the ctx->self and simply use
g_task_get_source_object(). In some cases, that removes the need to
have a context struct as well.


>
> --
> Aleksander
> https://aleksander.es
> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel


More information about the ModemManager-devel mailing list