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

[Ignacy G. <sf...@qu...>]

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.

-- 
 "The whole problem with the world is that fools and fanatics are
   always so certain of themselves, and wiser people so full of doubts."
                                                 - Bertrand Russell