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

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

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

> Ignacy
>
Paolo