Round 1 - focus on headers.
For classes with initial in range [L-O].
Try to keep the same separators between different kind of headers.
Drop changes to NameValueDictionary for now, as apparently
environmentfwd.h is broken currently. It looks we can't
forward declare the argument T inside QList<T> - the type
must be complete.
Change-Id: If26e88357a2ffbb91a79c4d003046443d98d5673
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: hjk <hjk@qt.io>
It's a result of a team work consisting of yellow triangle and me.
Change-Id: I8b4812766da70e0785ae71bf0cb71357379e2514
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Instead of holding the start packet on caller side when
launcher socket isn't ready yet, pass it into the launcher
socket and buffer it there until the socket becomes ready.
This simplifies starting the process considerably.
Get rid of CallerHandle::canWaitFor(), as this is already
checked by QtcProcess itself.
Get rid of LauncherHandle::m_waitingFor field and
LauncherInterface::isReady() method, as both are not used anymore.
Change-Id: Ida6f0629170647249e562028c3ea5db1830b8a0d
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Give process launcher a chance to finish its processes
gracefully before we finish process launcher's process in Creator.
Otherwise, when Creator's process reaper kills the process
launcher's process while the process launcher is still
reaping its processes, the process launcher may leave zombies.
Instantiate the ProcessReaper inside ProcessReaper::reap(),
otherwise its destructor won't run at all inside process launcher.
Reverts e45e16d904
Fixes: QTCREATORBUG-27118
Change-Id: I00290cda05538b5a7ecbeb08240d1e3772d43d62
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Process launcher: Reap all running processes in
LauncherSocketHandler destructor. Do it only once.
Warn about running processes.
From Creator side: Don't disconnect launcher's process
until it goes into the Creator's reaper.
Change-Id: I8af8e0247290cc07846fbf88b1521307293eed39
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Drop it also from registerHandle() methods, as it wasn't
used there.
Change-Id: I34b72c38368b82f22d73314fe3cd429ed43cadbc
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The socket/name for QLocalServer must be a path that is short enough for
unix sockets (<= 104 chars).
QLocalServer already ensures that the "name" is an absolute path, by
prepending QDir::tempPath() if it isn't. For Qt Creator that worked, but
the temporary directory set up for the unittests resulted in a too long
combined path.
Also, we should avoid directly using QDir::tempPath() and use
Utils::TemporaryDirectory to keep all our temporary files at one place.
So, make the "name" explicitly an absolute path in our specific
temporary directory, and make the name shorter for the test.
See 6feed6e656 for a similar issue.
Change-Id: I07dc4233db1c9d353cd6977da43850256057ba55
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
Reviewed-by: hjk <hjk@qt.io>
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>
Reuse ProcessReaper inside process launcher.
Automatically reap all internal QProcesses of QtcProcess
(either direct child of QtcProcess in QProcessImpl
or indirectly inside process launcher).
Make ProcessReaper work again on QProcess instead of on
QtcProcess, so it may still be reused for non-QtcProcesses.
Change-Id: I950cac5cec28f17ae97fe474d6a4e48c01d6aaa2
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: hjk <hjk@qt.io>
Sometimes after creating QtcProcess we move it into a different
thread. In this case we should move all the children, too.
Without parent-child relation all the children will stay in the
old thread.
Change-Id: Ibde44d6153092a155dd2d200a7116a046910dddc
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Instead of returning a pointer to LauncherSocket instance,
which might get deleted in meantime of just after,
route all calls to the LauncherSocket through the LauncherInterface.
Make all calls to LauncherInterface secured by the
instance mutex.
Change-Id: I751228de5f4263112471098ee08cc73a5245147e
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
LauncherInterface::stopLauncher() ensures now that a posted call to
doStop() is being executed before we delete the laucher's thread.
Change-Id: I80f4136810e113bcaa1427eca7906d710cc770de
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Change the lifetime of LauncherInterface. Now it's being
constructed when startLauncher() is called and
destructed on stopLauncher(). Before, we hold the
static LauncherInterface object and couldn't control when
it's being destructed, so in fact the destruction
started too late, after the QtSingleApplication's destructor
finished.
Simplify LauncherInterface::isStarted() method.
Change-Id: I91f38212177318746d2530a418eb3efd3d9258cb
Reviewed-by: hjk <hjk@qt.io>
Get rid of <QtModule/qclass.h> style and use <QClass> directly,
like in all other places in Creator. Remove some unneeded
declarations.
Change-Id: I1b5630850c570e5d86df01a341f7352bc1971e48
Reviewed-by: hjk <hjk@qt.io>
Add some developer comments explaining which method
is designed to be called from a certain thread.
Add also some comments about in which thread
certain QObjects live in.
Change-Id: I38b10216cc29f8a86fd784e588e913407f0fb776
Reviewed-by: hjk <hjk@qt.io>
Move launcher process into a separate thread.
Implement blocking API by using wait condition
on the caller's side. Replay all collected
signals from the launcher's thread when leaving
waitingFor* state. In case we were not waiting
for anything deliver the signals asynchronously
from launcher's thread to the caller's thread.
Change-Id: Id44fe5f7ceaac407004984a1dfb6ea65f197d297
Reviewed-by: hjk <hjk@qt.io>
