If there are still open channels in a connection being released,
that is not necessarily a mistake: The channels could already be
in the closing state, and it would be unreasonable for us to expect
API clients to always wait for confirmation before releasing the
connection, as this can complicate code quite a bit, turning a
synchronous operation into an asynchronous one.
Change-Id: If8c604c9ee1294728e7947c8d5c8130d6e704b49
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
We can't just pretend a channel is already gone after we request it to
close; it's only closed when the server has sent the acknowledgement.
Change-Id: Ib6e8b9bf77635995259885af13755f5fc0e825a9
Reviewed-by: Tobias Hunger <tobias.hunger@nokia.com>
Otherwise a new client acquiring the connection could be affected by
things happening in channels that were not opened by that client, which
would certainly be unexpected.
In particular, if the new owner of the connection runs in a different
thread than the old one, crashes could occur since the connection
assumes its channels run in the same thread.
Change-Id: I4fdf2b5a3751ed506631d6878e94342da033c31c
Reviewed-by: Tobias Hunger <tobias.hunger@nokia.com>
It used to be shared pointers so that existing connection objects could
easily be passed around in order not to open a new connection to the same
server. Since the introduction of the SshConnectionManager, this
is no longer necessary.
Change-Id: I13fd3eceaf35d562e6260e9969abbffb01edd6b5
Reviewed-by: Tobias Hunger <tobias.hunger@nokia.com>
It does not belong into libUtils, which is a collection of small
unrelated utility classes.
Task-number: QTCREATORBUG-7218
Change-Id: Id92b9f28678afec93e6f07166adfde6550f38072
Reviewed-by: Eike Ziller <eike.ziller@nokia.com>
