KMaiL: Can't setup D-Bus service. Probably already running.

[Ralf Habacker]

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.
>
>   
>> http://lists.freedesktop.org/archives/dbus/2008-February/009328.html
>>
>> 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 
still remain.

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 
dbus code.

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 
http://msdn2.microsoft.com/en-us/library/ms740476(VS.85).aspx  looks 
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.

Ralf