[Bug 42503] Race in tp_channel_dispatch_operation_claim_with_async() and context_accept()

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=42503

--- Comment #7 from Xavier Claessens <xclaesse at gmail.com> 2011-11-07 05:26:41 PST ---
(In reply to comment #6)
> What happen if user calls tp_channel_dispatch_operation_claim_with_async() on
> an unprepared object?   _tp_base_client_now_handling_channels (client,
> self->priv->channels); will fail and leave/destroy variant won't work?

Actually in that case self->priv->channels is NULL, so claim_with will do a
g_return_if_fail inside _tp_base_client_now_handling_channels, and
leave/destroy will just crash when doing self->priv->channels->len.

So you're right that those APIs should g_return_if_fail(tp_proxy_is_prepared())
to early-return.

> Any reason why a user would want to use tp_channel_dispatch_operation_new()?
> Shouldn't we deprecate it?

Indeed, I don't see any reason for an app to use that. This is the same story
than tp_channel_new() and all other TpProxy subclasses constructors. We
actually even kept _tp_simple_client_factory_ensure_channel_dispatch_operation
private because there were no reason it to be useful.

I would just leave it for now, we should deprecate all proxy constructors at
once, IMO. I'm not sure we have a bug for that, though.

> Did you double check that tp-glib is always preparing it itself?

The only place a CDO is created is from TpBaseClient, and I've fixed that case,
yes.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.