tp_list_connection_managers is implemented as follows:
* Asynchronously, call ListActivableNames
* For each returned name, if it looks like a connection manager, add it to a map from name ⇒ TpCM
* Asynchronously, call ListNames
* For each returned name, if it looks like a CM and isn't already in the map, add it.
* Now call the callback passed to tp_list_connection_managers
When you construct a TpCM, an idle callback is added to read the .manager file; when it's read, got-info fires on the TpCM.
The intention is that when tp_list_connection_managers calls the user-supplied callback, none of the CMs have had their .manager files read, or been introspected. However, the idle callbacks to read from the .manager file might have already been called, so any given TpCM's got-info(CACHED) signal might already have fired. So the callback gets a list of TpCMs in different states.
This is undesirable. :-)
This is actually worse than I thought: sometimes introspecting a running CM also happens before the callback is called!
I was apparently wrong about introspection of a running CM happening before the callback fires, and think I have a solution for the original bug.
Also, if the .manager file is not found, got-info is never emitted. However, if it is found but reading it fails, got-info (NONE) is emitted.
http://git.collabora.co.uk/?p=user/smcv/telepathy-glib-smcv.git;a=shortlog;h=refs/heads/cm contains an untested fix for failure to emit got-info if no .manager file exists. The API needs fixing (Bug #18291), this is only a short-term solution.
Users of TpConnectionManager can avoid the problem that got-info might already have been fired by looking at tp_c_m->info_source directly. (Again, this is a short-term fix for what's already there, not a long-term solution.)
Adding mardy to Cc since telepathy-mission-control is interested in this API too.
(In reply to comment #4)
> contains an untested fix for failure to emit got-info if no .manager file
> exists. The API needs fixing (Bug #18291), this is only a short-term solution.
I didn't try your patch yet, but it seems to me by looking at the code, that the problem also occurs if manager_file is NULL, in which case tp_connection_manager_read_file() won't be executed even with your last change.
Fixed in 0.7.26