KMaiL: Can't setup D-Bus service. Probably already running.
thiago at kde.org
Tue Feb 19 17:30:16 GMT 2008
On Tuesday 19 February 2008 15:56:34 Ralf Habacker wrote:
> ... 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.
It detects that the connection closed in its select() main loop. When one
client goes away, the (Unix) socket closes automatically and immediately. The
dbus-daemon then gets a read notification. When it tries to read, it gets 0
bytes, indicating EOF. Then it proceeds to release all resources associated
with that client.
That's on Unix. I have no idea how you guys implemented the mainloop on
Windows. I know the Qt event loop uses a WSAAsyncSelect, but that's not
necessary for dbus-daemon (since it has no GUI). It can use a normal,
Unix-style select() with timeout.
> 2. Is the behavior, Christian reported about the delay on closing
> sockets on windows and it difference to unix somewhere documented ?
No idea. It might be a difference between TCP and Unix sockets. I.e., the
operating system tries to send unsent bytes after the socket closes --
including when the app terminates or crashes.
This should not happen since there should be no unsent bytes.
But in all implementations, sockets close when the application that had them
open exits. It does not make any sense at all to keep a socket open past the
So, one of two conditions:
1) the socket did close, but dbus-daemon.exe did not notice it. It's probably
a Windows porting bug or some kind of stupid Winsock behaviour. I can't see
anything special about handling remote closes on Qt's Windows code.
2) the socket somehow did not close, but this doesn't make sense if the
> 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.
I don't know. If we set to not linger, then we may be throwing away some D-Bus
messages that should've been sent.
> 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.
It CANNOT be properly fixed in KDE code.
What happens to non-KDE Qt applications? How about other D-Bus applications
running with libdbus-1? Or without it (like the Java or NDesk/C# bindings)?
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel