[Bug 23639] Port to Wocky

[bugzilla-daemon at freedesktop.org]

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





--- Comment #5 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk>  2009-09-02 06:11:47 PST ---
(In reply to comment #3)
> Tests:
> 
> +        if conn.GetStatus() == cs.CONN_STATUS_CONNECTED:
> +            # Connection is connected, properly disconnect it
> +            disconnect_conn(queue, conn, stream)
> +        else:
> +            # Connection is not connected, call Disconnect() to destroy it
> +            conn.Disconnect()
> 
> I don't get this: if the connection's not connected, it could be either
> CONNECTING (in which case, Disconnect() works) or DISCONNECTED (in which case,
> Disconnect() is either redundant (it's about to die anyway) or not right (if
> the connection hasn't started connecting yet, does Disconnect() kill it?)

In the CONNECTED case, we have to wait for the stream-closed event and send the
close too (Disconnect is async).
We can't do that if the connection isn't connected.

> +  /* It appears that dbus-glib registers a filter that wrongly returns
> +   * DBUS_HANDLER_RESULT_HANDLED for signals, so for *our* filter to have any
> +   * effect, we need to install it as soon as possible */
> 
> Did you file a bug?

No, I stole this comment from telepathy-glib/run.c.
I can open one of you want.

> main() in main-debug.c never unrefs its TpDBusDaemon.

fixed.

> Why is the Disconnected filter necessary, anyway?

When running in tests, Gabble is generally killed because of this signal. By
catching it, I can run wocky_deinit () before exiting the process and so
produce a more useful Valgring report.


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