Re: [dbus-cplusplus-devel] Server and closing connections

[P. D. <sh...@gm...>]

On Thu, Sep 4, 2008 at 5:42 PM, Ignacy Gawedzki <sf...@qu...> wrote:
> On Thu, Sep 04, 2008 at 12:17:42AM +0200, thus spake P. Durante:
>> Hi,
>>
>> On Wed, Sep 3, 2008 at 10:50 PM, Ignacy Gawedzki <sf...@qu...> wrote:
>> > Hi,
>> >
>> > I'm playing with dbus-c++ for two days now and I stumbled upon a particular
>> > problem related to using DBus::Server.
>> >
>> > It seems that this part of the code needs some work and that most of the
>> > people simply don't care, since, please correct me if I'm wrong, it's used
>> > only in peer-to-peer communications (i.e. not going through dbus-daemon).
>> >
>> to be honest, as far as I know, it's not used at all
>>
>> > Of course I could for now go along with using dbus-daemon and not care about
>> > DBus::Server that much, but I'm still wondering how to make that thing work
>> > right.
>> >
>> > A major problem with DBus::Server is the way DBus::Connection objects are
>> > dealt with and more generally the fact that there apparently is no clean way
>> > of cleaning up stuff on client disconnection.  As for DBus::Connection
>> > instances, they obviously are never removed from the
>> > DBus::Server::Private::connections list.
>> >
>> right
>>
>> > The thing is that after looking into the libdbus API and having searched
>> > through the mailing list archives, it seems to me that there is a deeper
>> > problem with detecting client disconnections.  A watch does not hold any
>> > reference to the connection it's associated with and relying on connections
>> > (and also watches) to have an associated file descriptor (that might be used
>> > to match the one with the other) is not a good way to go, according to the API
>> > docs (a connection is not necessarily associated with a file descriptor).  So
>> > at no point is there a way to associate a watch to its connection, so as to
>> > check whether it's still connected after a watch handling, or something like
>> > that.
>> >
>> > Do you see any way of achieving this?
>> >
>> if I understand the question correctly, the internal data pointer
>> which is now used to store the
>> Dispatcher associated with the Watch could be replaced with a pointer
>> to the Connection owning the watch
>> http://dbus.freedesktop.org/doc/dbus/api/html/structDBusWatch.html#ec763277e3fd3a3fbf34ea5bd7dda617
>> (the dispatcher will still be accessible through the connection object)
>>
>> then, a special case to handle a closing connection could be added to
>> DBus::Watch::handle()
>> (checking for POLLHUP|POLLERR)
>>
>> out of curiosity, I've looked at how the Qt people do it but
>> apparently they didn't implement it either
>> http://lists.kde.org/?l=kde-devel&m=120185882521538&w=2
>
> After having looked at that again and more from the libdbus API standpoint, I
> have noticed that in any case the disconnection should be noticed and that in
> fact, in dbus-c++, the Connection::Private::do_dispatch() method does check
> whether the connections is terminated (by a call to
> dbus_connection_get_is_connected()) and calls
> Connection::Private::detach_server() in that case.
>
> It seems there are more serious issues with the lifetime management of
> Connection::Private instances, which are created but never freed it seems.
> Before I can go further with my initial problems, I must resolve these.
>
do you have any evidence? dbus_connection_unref is called in the
destructor for this very reason, and calls to ref/unref are balanced
so to keep the Connection::Private (and the internal DBusConnection)
around for as long as there's at least a DBus::Connection referring to
it