Introduce Utils::Singleton class and
Utils::SingletonWithOptionalDependencies class template
that helps implementing singletons that depend on other
singletons. It's guaranteed that whenever singleton B depends
on singleton A, than A is always created before B is being
created, and that the order of destruction is always
opposite to the order of creation.
Dependencies of singleton are listed as template arguments
for SingletonWithOptionalDependencies class template.
The first argument of SingletonWithOptionalDependencies
class template is always a singleton class itself.
Prepare a common interface for all singleton subclasses:
SingletonSubClass *SingletonWithOptionalDependencies::instance();
Make instantiating singletons and its dependencies thread-safe.
Create singletons on demand (only if some code needs them).
It's not needed anymore to explicitly instantiate
all required singletons in tests.
Make it possible (and thread-safe) to instantiate ProcessReaper
and LauncherInterface singletons in non-main threads.
Make the following dependencies between existing singletons:
SshConnectionManager depends on:
-> LauncherInterface depends on:
-> ProcessReaper
Change-Id: Iefaacab561c2b3dcf07e7fafbb87339ea6a15278
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Make it possible to control when the SshProcessManager is
being constructed / destructed. Expose public constructor.
Since different singletons depend on each other, we need
to control the order of creation and destruction of them.
The order of creation is like that:
1. QCoreApplication
2. ProcessReaper
3. ProcessLauncher
4. SshConnectionManager
The order of destruction must be opposite to the above.
Change-Id: Ice07eb751cd61c03cb461816fa1b74ab040a53de
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
The SshConnection wasn't used in non-main thread anyway and the
implementation couldn't work properly in multiple threads.
Fix "acquire" typo in variable and class names.
Make SshConnectionManager a child of application object, so that
it will be deleted together with it.
Replace forever with ranged for loop.
Change-Id: I3c3592eb5ce20b463d5a656f94cadaccccf652dc
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Unshared connections are not re-usable, so our whole book-keeping
procedure is not needed for them.
Change-Id: I1b6ca3d1658d139b6687425cf32f821548dddade
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
We do it wherever possible. Some places can't be fixed
since they still rely on dynamic introspection
(mainly QQuickItem cases).
Change-Id: Ia00b4a04d8b995c9a43b7bf2dbe76a60364bb8ca
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
... instead of our own SSH library.
Advantages:
- Full compatibility with OpenSSH behavior guaranteed.
- Minimal maintenance effort.
- Less code to build.
- Big chunk of 3rd party sources can be removed from our repository.
One the downside, Windows users now need to install OpenSSH for
RemoteLinux support. Hoewever, people doing embedded development
probably have it installed anyway.
[ChangeLog] Switched SSH backend to OpenSSH
Fixes: QTCREATORBUG-15744
Fixes: QTCREATORBUG-15807
Fixes: QTCREATORBUG-19306
Fixes: QTCREATORBUG-20210
Change-Id: Ifcfefdd39401e45ba1f4aca35d2c5bf7046c7aab
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
The heavy lifting was done by clazy.
Change-Id: I04261849c92c54990f9f142fe541d984c5fb21d3
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
Probably just a thinko in the original code.
Change-Id: Ie089737a3501c5aede9a2234c10e4f1c1611d952
Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
We keep connections open to avoid re-doing the authentication procedure
when the user runs or deploys a remote app repeatedly.
However, the connections should not be around indefinitely; we therefore
now close them after about five minutes of inactivity.
Change-Id: Ie677eb133b618d34c08528da2f2bc221472316b3
Reviewed-by: hjk <hjk121@nokiamail.com>
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
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>
