KMaiL: Can't setup D-Bus service. Probably already running.
ralf.habacker at freenet.de
Tue Feb 19 14:56:34 GMT 2008
Thiago Macieira schrieb:
> On Tuesday 19 February 2008 14:16:44 Ralf Habacker wrote:
>> I agree as a last chance, but the dbus people suggests to unregister
>> services and/or pathes when they are no more needed and not to relay on
>> the tcp or unix socket connection close behavior.
>> If the connection is finalized (refcount reaches 0) your object path
>> is automatically unregistered. However, typically it's better to
>> unregister an object path at the point where you don't want it invoked
>> anymore; after all, someone else may be holding a refcount, and you
>> don't want the object path registration to accidentally stay alive,
>> especially if you freed the object it refers to.
> If you s/object path/service name/ in the paragraph above, it makes sense.
> Otherwise it doesn't: you can't ref-count a remote object path. It's
> impossible to know when it is no longer available unless the service it's on
> goes away.
> For KDE non-unique app service names (org.kde.appname-$PID), I see no need for
> ever de-registering. For unique app service names (org.kde.kded, for
> example), I also see no need for unregistering: it's present for the entire
> lifetime of the process.
> For services that we may claim or release, then we should also register and
> de-register at the proper times.
>> This supports to unregister in the destructor of the last
>> KUniqueApplication or KApplication object (may be in a static class
>> method) because registering was done in the creating of the first
>> KAppplication or KuniqueApplication or are I'm completly wrong ?
> From the message you linked to:
> "If your app is exiting, just exit, dbus_shutdown() is pointless."
> I say the same about service names.
Okay, it looks we can talk very long about where to fix this issue :-)
... but this does not help to find a solution for the reported issue,
which requires to work together to find a way out or this problem will
1. Which condition enables dbus to detect that a connection is close and
where in the dbus code is this located ? This is required to generate
testcases and/or find the right place for additional debug messages in
2. Is the behavior, Christian reported about the delay on closing
sockets on windows and it difference to unix somewhere documented ?
3. Are there any possible option in setting socket options ? The only
option I found in setsockopt
like to be
SO_DONTLINGER BOOL Does not block close waiting for unsent data to be
sent. Setting this option is equivalent to setting SO_LINGER with
*l_onoff* set to zero.
but I cannot say if the current problem is caused by unset data. If
there is no socket option it will be required to fix this issue in KDE's
code. I cannot see any way how to fix this in dbus.
More information about the kde-core-devel