--nextPart3350530.MiDKYzM8Xg
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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 =A0the 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=20
client goes away, the (Unix) socket closes automatically and immediately. T=
he=20
dbus-daemon then gets a read notification. When it tries to read, it gets 0=
=20
bytes, indicating EOF. Then it proceeds to release all resources associated=
=20
with that client.

That's on Unix. I have no idea how you guys implemented the mainloop on=20
Windows. I know the Qt event loop uses a WSAAsyncSelect, but that's not=20
necessary for dbus-daemon (since it has no GUI). It can use a normal,=20
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=20
operating system tries to send unsent bytes after the socket closes --=20
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 the=
m=20
open exits. It does not make any sense at all to keep a socket open past th=
e=20
application's lifetime.

So, one of two conditions:
1) the socket did close, but dbus-daemon.exe did not notice it. It's probab=
ly=20
a Windows porting bug or some kind of stupid Winsock behaviour. I can't see=
=20
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=20
application terminated.

> 3. Are there any possible option in setting socket options ? =A0The only
> option I found in setsockopt
> http://msdn2.microsoft.com/en-us/library/ms740476(VS.85).aspx =A0looks
> like to be
> SO_DONTLINGER =A0=A0BOOL =A0=A0=A0Does 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=20
messages that should've been sent.

> but I cannot say if the current problem is caused by unset data. =A0If
> 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=
=20
running with libdbus-1? Or without it (like the Java or NDesk/C# bindings)?

=2D-=20
=A0 Thiago Macieira =A0- =A0thiago (AT) macieira.info - thiago (AT) kde.org
=A0 =A0 PGP/GPG: 0x6EF45358; fingerprint:
=A0 =A0 E067 918B B660 DBD1 105C =A0966C 33F5 F005 6EF4 5358

--nextPart3350530.MiDKYzM8Xg
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)

iD8DBQBHuxIpM/XwBW70U1gRAlHoAJ9iGv1pDOCthtysG3eUQEw0V/gqKgCghVzo
gy5UjZWrnYtF6yIVs+jgf1Q=
=YH7n
-----END PGP SIGNATURE-----

--nextPart3350530.MiDKYzM8Xg--