RE: [Bluez-devel] Rfcomm Use Count

["Daryl Van Vorst" <daryl@wideray.com>]

Marcel,

> > With my suggestion above the condition would be handled by=20
> either accept()
> > or cleanup_listen(), whichever is called first. Though I=20
> guess you could
> > still consider that to be garbage collection.
>=20
> when it is handled in ..cleanup_listen() then it gets handled when you
> kill the server process. I think this is far too late, because you can
> have more than one connection attempts in between. We must handle this
> when we close the connection.

Agreed, but if bluez_accept_dequeue() returns closed connections then it =
can
also be handled in accept(). So this would only be an issue in =
situations
where a socket is listening for a long time without there ever being a =
call
to accept().

The topic of cleanup_listen() came up just because the only way it has
appeared for me in normal use was with incomming connections while the
server was being shut down. While the server is running, incomming
connections are returned by accept() before they get closed by the =
remote
side.

It is still unclear to me why I could not bind to the socket (error was
address already in use, 98) when I tried to restart the server. This
behaviour is not seen with the simple test program I sent last week (and =
so
might be unrelated).

> This is correct and so I don't really like this approach. I=20
> think there
> is a simply logic mistake in the closing path of the RFCOMM code.

Could be. Then the closing path of the rfcomm code would need to be able =
to
remove connections from the accept queue. This might be a difficult =
change.

-Daryl.