[Bug 24257] TpAccount, TpAccountManager: prepare never terminates if the object is invalidated

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=24257


David Laban <david.laban at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|jonny.lamb at collabora.co.uk  |david.laban at collabora.co.uk




--- Comment #3 from David Laban <david.laban at collabora.co.uk>  2009-10-28 05:17:45 PST ---
Okay, so I've taken a look through the code, and I think I have something which
might work, but it seems somehow too easy. If it looks like an obviously stupid
idea then shout and I can avoid wasting too much time.

Current Situation
===================


Looking at the code, it seems that the only place where prepare_async is called
is from tp_account_manager_ensure_account. If prepare_finish returns an error,
it is silently ignored (_tp_account_manager_account_ready_cb silently returns).
Therefore, having prepare return an error won't actually do anything in this
case.

There is an _tp_account_manager_account_invalidated_cb but it is only
registered if/when prepare finishes successfully. Also, it only listens for
domain == TP_DBUS_ERRORS && code == TP_DBUS_ERROR_OBJECT_REMOVED. Are there any
other cases/reasons why an account might be invalidated?

Proposed solution
====================

1) Register account_invalidated_cb in ensure_account rather than in
account_ready_cb.

2) For completeness if anyone else wants to call prepare_async and get called
back.

define _tp_account_invalidated_cb () which loops over priv->callbacks and makes
them all fail. I think I know how to do this, after reading the gio docs.

Register invalidated_cb with the invalidated signal (somewhere inside
_tp_account_constructed)

Concerns
=========

I suspect that there's some memory management that's going to mess me up here:
If you connect to a signal on yourself, does it add a ref to you like it does
in python? If so then will we be kept alive forever? Would it be better to
register a separate signal for the duration of the prepare (register each time
prepare is called, keeping the id in priv->callbacks, and unregister it when
we're done)?



Also: do you want a test for this? If so, that might be a little harder because
I don't know what else calls prepare, and just implementing 1) would fix the
account_manager case.


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