summaryrefslogtreecommitdiffstats
path: root/src/corelib/io/qprocess_unix.cpp
Commit message (Collapse)AuthorAgeFilesLines
* QProcess: untangle platform-specific detailsAlex Trotsenko2021-06-041-0/+61
| | | | | | | | | - add missing #ifdef in header file; - split some functions (writeData(), _q_canWrite(), cleanup()) into their platform-specific implementations. Change-Id: I4e7c1c377ec8468ed120d38acf2543eef9316c01 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* Introduce QProcessPrivate::closeChannels()Alex Trotsenko2021-05-311-6/+2
| | | | | | | Avoid duplicating code for both platforms. Change-Id: Iae00023672b63e8539cf824fa3aaaff2bf9ae0c5 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* Consolidate debug string generationAlex Trotsenko2021-05-311-46/+4
| | | | | | | | | | | | | | Several QIODevice subclasses use the qt_prettyDebug() function to get a printable representation of the buffer data for debug output. Rather than having this feature statically implemented in each respective file, this patch introduces a generic function in the QtDebugUtils namespace. Accordingly, some inaccuracies in the use-cases have been corrected. Change-Id: I1a8465cab08c8acf5fdcdba5085182511b1cbb7b Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QProcess/Unix: fix build in debug modeAlex Trotsenko2021-05-231-1/+1
| | | | | | | qprocess_unix.cpp:633:55: error: ‘i’ was not declared in this scope Change-Id: I152fbd9df6e9d3f31e2c2c8b23a3c1ab87aa237a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QProcess/Unix: add a RAII class to hold the argv and envp pointersThiago Macieira2021-03-091-71/+79
| | | | | | | | Instead of having so much manual pointer manipulation and duplicated code. Change-Id: Ic90d8429a0eb4837971dfffd1664f8f63753440a Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* QProcess/Unix: use a common function to find the target executableThiago Macieira2021-03-041-48/+39
| | | | | | | | | | | | | This harmonizes the execution between start() and startDetached(). Both did QStandardDirs::findExecutable(), but duplicated code. However, only start() supported launching .app bundles on Mac. [ChangeLog][QtCore][QProcess] startDetached() now supports launching .app executable bundles on macOS / iOS systems, like start() already did. Change-Id: Ic90d8429a0eb4837971dfffd1664f776b2c0edfd Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* QProcess/Unix: remove outdated notices about use of posix_spawn() on QNXThiago Macieira2021-02-211-4/+0
| | | | | | | | | We haven't used the spawn functionality on QNX since Qt 5.7 (commit 005a8bfbf0022f03dafafcf2b5c438ccf0675a49) because that's when we dropped support for QNX 6.5.0. Change-Id: Ic90d8429a0eb4837971dfffd1664f9712bdce2d8 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* QProcess::startDetached/Unix: report which function failedThiago Macieira2021-02-211-30/+42
| | | | | | | | Like QProcess::start(). Pick-to: 6.1 Change-Id: Ic90d8429a0eb4837971dfffd1664ef1293a6523d Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* QProcess::startDetached/Unix: simplify handling of the pipesThiago Macieira2021-02-211-21/+26
| | | | | | | | | | | | | Use a structure that will automatically close them for us. This doesn't apply to startProcess() because the pipes there are long-lived (though each of them in QProcessPrivate could be an AutoPipe...). The destructor only runs in the parent process, so the child processes don't need to worry about setting file descriptors to -1. Pick-to: 6.1 Change-Id: Ic90d8429a0eb4837971dfffd1664ed98f3d74d1c Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* QProcess::startDetached/Unix: remove unnecessary ignoring of SIGPIPEThiago Macieira2021-02-211-10/+0
| | | | | | | | | This is unnecessary because we can only get SIGPIPE if the reading end of the pipe is closed. And that can only happen if the parent process has exited, meaning there's no one to read our message anyway. Change-Id: Ic90d8429a0eb4837971dfffd1664ec6821993ada Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* QProcess::startDetached/Unix: fix the resetting of SIGPIPEThiago Macieira2021-02-221-5/+1
| | | | | | | | | | | | | This should have been SIG_DFL, as we're about to execute a child process. It's the child's responsibility to ignore SIGPIPE if it wants to, or get killed by it when it writes to an pipe with no readers. Qt itself does this for its own purposes (see qt_ignore_sigpipe() [until I can get some time to teach Linux about O_NOSIGPIPE]). Therefore, we ought to reset what we've done. Change-Id: Ic90d8429a0eb4837971dfffd166585a686790dde Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* QProcess::startDetached: set the error condition on failure to startThiago Macieira2021-02-211-9/+19
| | | | | | | | | | | | And set *pid to -1. [ChangeLog][QtCore][QProcess] If a startDetached() fails to start the target application, the QProcess object should now have a proper error string in errorString(). Pick-to: 6.1 Change-Id: Ic90d8429a0eb4837971dfffd1664e825ffcb923e Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* QProcess::startDetached/Unix: move up the chdir() and remove qWarningThiago Macieira2021-02-181-6/+6
| | | | | | | | | | That qWarning cannot be in the child process (we don't know if a user logger is fork-no-exec-safe) and the failure to chdir() should be reported as a failure in QProcess::startDetached() instead. Change-Id: Ic90d8429a0eb4837971dfffd1664e7577c81610b Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Reviewed-by: David Llewellyn-Jones <david.llewellyn-jones@jolla.com>
* QProcess/Unix: remove unnecessary chdir("/") before _exit()Thiago Macieira2021-02-181-2/+0
| | | | | | | | | That only created an opportunity for qWarning(), which should never be in the child process in the first place. Change-Id: Ic90d8429a0eb4837971dfffd1664e57a2291ea78 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Reviewed-by: David Llewellyn-Jones <david.llewellyn-jones@jolla.com>
* QProcess/Unix: remove dead functionAlex Trotsenko2021-01-291-4/+0
| | | | | | | | findExitCode() doesn't do anything on Unix. Change-Id: I3efdc1380a39437c4c029073f3b10ccf7a65e580 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QProcess/Unix: simplify notifiers deactivationAlex Trotsenko2021-01-271-0/+3
| | | | | | | | To minimize code duplication, move the socket notifier deletion to the closeChannel() function, where the pipe descriptor will be closed. Change-Id: If75ba1c955c706ae6e2b3d9f53f7a25e4aa32fa7 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* QProcess/Unix: do not activate read notifiers until process has startedAlex Trotsenko2021-01-091-2/+6
| | | | | | | | Otherwise, the user may receive the readyRead() signal just before started(). Change-Id: I8d6fd18fdfcef0580a3e609100198b03b18b1175 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* Split QProcessPrivate::_q_processDied()Alex Trotsenko2021-01-091-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The completion of the child process can take place asynchronously or in one of the waitFor...() functions. In both cases, we used the same handler (_q_processDied()), which caused several problems: a. technically, waitForReadyRead() should have taken into account the result of the calls to _q_canRead...() slots inside the _q_processDied() function: - the user calls waitForReadyRead(); - forkfd descriptor becomes signaled, while a grandchild process is still alive; - as readyRead() signal has not been emitted, _q_processDied() is called; - the grandchild process writes to stdout pipe; - now data arrives, and _q_processDied() will collect it, but won't report it. b. we had a bug with recursions on Unix: - death notification comes asynchronously; - waitForDeadChild() closes forkfd; - _q_canRead...() emits readyRead(); - a slot connected to readyRead() calls waitForFinished(); - waitForFinished() hangs (forkfd == -1). c. for blocking functions, drainOutputPipes() was called twice on Windows. By introducing a new processFinished() function, we leave the read operations in the _q_processDied() slot, while the process completion code is guaranteed to run only once. Change-Id: I5f9d09bc68a058169de4d9e490b48fc0b35e94cd Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* QProcess/Unix: consolidate process state tracking socket notifiersAlex Trotsenko2021-01-081-17/+26
| | | | | | | | | | | | | | | | There is no reason to have the startup notifier and the death notifier be active at the same time, as the former will detect death as well. Previously, these notifiers were racing, but _q_processDied() ordered signals by calling _q_startupNotification() manually. Thus, the started()/finished() sequence was always emitted if the child process was killed anywhere. Now this ordering is simply not necessary anymore. This makes it possible to reuse the startup notifier for death notification. Change-Id: I5ebed9b5f28b19fe56c80498977a3b21be9288fd Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* QProcess: allow merged channels forwarding for detached processesAlex Trotsenko2020-12-311-23/+22
| | | | | | | | [ChangeLog][QtCore][QProcess] Added support for QProcess::MergedChannels mode with startDetached(). Change-Id: I953ad2063322015332269522a297f8e2842e438c Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* QProcess: consolidate channel managementAlex Trotsenko2020-12-311-32/+2
| | | | | | | | | | We have the same channel forwarding, redirecting, and merging rules for all platforms. This makes it possible to introduce the openChannels() function, which consolidates the logic and performs high-level general processing of the channels configuration properties. Change-Id: Id3574fc42a56829328369b6a1a6ec9c95fce8eca Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* QProcess/Unix: speed up initialization of write notifierAlex Trotsenko2020-12-181-3/+2
| | | | | | | | By using new QSocketNotifier API, we can avoid unnecessarily enabling the notifier right before turning it off again. Change-Id: Ie0dea00251e9885653677c495dfc5abaaa4db1c7 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* QProcess/Unix: do not create pipes for forwarded channelsAlex Trotsenko2020-12-171-13/+28
| | | | | | | | | | | | | | | | | | The child process inherits a standard handle of the main process in such cases: stdin - inputChannelMode == QProcess::ForwardedInputChannel, stdout - processChannelMode == QProcess::ForwardedChannels || processChannelMode == QProcess::ForwardedOutputChannel, stderr - processChannelMode == QProcess::ForwardedChannels || processChannelMode == QProcess::ForwardedErrorChannel || processChannelMode == QProcess::MergedChannels For these combinations we should not create pipes and notifiers as they would not be used. Change-Id: I8e3836e4d840a40b338c85c54645539ebcaab3f6 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* QProcess/Unix: unify waiting in 'Starting' stateAlex Trotsenko2020-12-091-21/+2
| | | | | | | | | | | It makes no sense to poll the I/O pipes if we didn't get a start-up notification yet. And in fact, all waitFor...() functions except waitForReadyRead() did already explicitly wait for process startup completion. So fix that one up, and remove the handling of 'Starting' state from the I/O loops. Change-Id: Ibb7eb7c768bef3f9b6c54009c73b91775570102c Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* QProcess: migrate to QDeadlineTimerAlex Trotsenko2020-12-091-29/+17
| | | | | | | | | Replacing QElapsedTimer with QDeadlineTimer simplifies the code in waiting functions, which also improves readability. Change-Id: I56aedd356b547b6735ed0985dc81be706e292437 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QProcess: simplify the logic around _q_processDied()Alex Trotsenko2020-12-061-9/+8
| | | | | | | | | | | Both on Unix and Windows, _q_processDied() unconditionally releases all resources associated with the terminated child process, resets QProcess to the initial state, and emits finished() signal. Thus, we can omit reporting success, which also eliminates the related checks from callers. Change-Id: I40e32d1a9ccc8d488be6badba934355d734a8abd Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* QProcess/Unix: remove redundant checks in waitForReadyRead()Alex Trotsenko2020-12-011-10/+7
| | | | | | | | | QProcessPrivate::tryReadFromChannel() returns 'true' only if we emitted readyRead() signal on the current read channel. Thus, these additional checks are unnecessary. Change-Id: Id98620cd08ee8808f60539c009986b869e517ef0 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* don't ever force fork() instead of forkfd()Oswald Buddenhagen2020-11-161-10/+0
| | | | | | | | | | | | | | | | | | | | | | | | this implements a suggestion made by a comment that got lost in 028ddf363: as explained in 97645478's commit message, we were forcing use of fork() because we couldn't be sure that the code in a custom setupChildProcess() did not rely on pthread_atfork() callbacks being called. however, that in turn was inconsistent with the default behavior, and made customizing QProcess mutually exclusive with benefitting from forkfd(). use the opportunity presented by changing the method of modifying child process behavior to also change this. this also amends 4e2f4670, as most of the now deleted comment in fact related to the use of vfork semantics, which we don't do anymore. [ChangeLog][Important Behavior Changes][QtCore][QProcess][Unix] pthread_atfork() callbacks are consistently not invoked on reasonably recent Linux and FreeBSD systems any more. This was already the case in later Qt 5 releases, unless setupChildProcess() was overridden. Change-Id: Icb239e4d2c705bf4665589469022a521267f7db5 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Avoid doing kill(-1) in QProcess destructorDimitrios Apostolou2020-10-291-4/+5
| | | | | | | | | It can happen under unspecified conditions, see relevant ticket. Task-number: QTBUG-86285 Pick-to: 5.15 Change-Id: I1f77bf0061a0faaa60283bb93fc3d82031247d54 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove typedef Q_PIDFriedemann Kleint2020-10-021-1/+1
| | | | | | | | | | | It is not used in public API any more since 0f8848b7e25e4d8fb9265ff6e0aa31946addd741. Replace by an internal Windows-specific Q_PROCESS_INFORMATION typedef. Change-Id: Ia6dcc83ca667c40ac5d678c00d143c09d650e42a Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Make usage of forkfd_pidfd in QProcess a configurable featureAlexandru Croitor2020-09-171-0/+6
| | | | | | | | | | | | | | | | | | | Our CI cross-compiling arm qemu builds have issues in tests that use QProcess, due to user-space qemu seemingly not supporting pidfds properly. Add a 'forkfd_pidfd' configure.json feature, which can be manually disabled when configuring Qt, causing QProcess to do a regular fork instead of using the new pidfd kernel feature. This will help us avoid the regression of multiple tests failing on the new Ubuntu 20.04 CI host images when they are run via qemu. Task-number: QTBUG-86285 Task-number: QTBUG-86187 Task-number: QTBUG-86198 Change-Id: Ib2209d7e95126e0fb738bf59e39070d5a62c482f Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QProcess/Unix: introduce setChildProcessModifier()Thiago Macieira2020-09-081-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ChangeLog][Source-Incompatible Changes] QProcess::setupChildProcess() was removed. To execute code in a child process, use QProcess::setChildProcessModifier() [ChangeLog][QtCore][QProcess] Added setChildProcessModifier() function with which one can provide code to be run in the Unix child process between fork() and execve(). With this function, it is no longer necessary to derive from QProcess in order to execute actions in the child process. Another reason is that we can tell whether the std::function carries a valid target much more easily than we can tell whether QProcess was overridden. The setupChildProcess() virtual function does not need to be marked final, since no overrider could ever return an inaccessible private class. This also makes sure the error presented to the user is about the return type, not about attempting to override a final. Clang: error: virtual function 'f' has a different return type ('void') than the function it overrides (which has return type 'QProcess::Use_setChildProcessModifier_Instead') GCC: error: conflicting return type specified for 'virtual void MyProcess::setupChildProcess()' note: overridden function is 'virtual QProcess::Use_setChildProcessModifier_Instead QProcess::setupChildProcess()' ICC: error: return type is neither identical to nor covariant with return type "QProcess::Use_setChildProcessModifier_Instead" of overridden virtual function "QProcess::setupChildProcess" MSVC is not relevant since it doesn't compile to Unix. Change-Id: Ia8b65350cd5d49debca9fffd15f801161363aea7 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* forkfd: remove FFD_VFORK_SEMANTICSThiago Macieira2020-06-301-2/+0
| | | | | | | | | | | | | | | This will never work, not unless libc implements it themselves, since the child process is not allowed to return from the function that does the vfork(), as subsequent use of the stack would trash the frozen parent's return address, and in our case that's syscall(). Instead, we may add a vforkfd() function that takes a callback function that will be called in that context, like the glibc clone(3) wrapper does. Pick-to: 5.15 Change-Id: I1dba29bc0f454df09ca1fffd161800b453c00593 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* Introduce QSocketNotifier::activate(QSocketDescriptor, QSN::Type)Mårten Nordheim2020-04-161-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pre-existing overload passes an int, but this can mean the descriptor gets truncated in compilations where the descriptor is 64-bit. The old overload with int is visible when querying the metaobject system so string-based connects still work as before, and connecting to it will produce a deprecation warning in the output. At the same time the PMF-based connect will, on recompile, pick the QSocketDescriptor overload. As an added improvement it also comes with the notification type, removing the need for separate slots where the code would be mostly shared anyway. The QSocketDescriptor type can be implicitly converted to and from qintptr to ensure existing code still compiles. It can also be constructed from Qt::HANDLE on Windows. In this same patch I also update the existing string-based connects in this module, which then includes updating the parameters for some slots as well. [ChangeLog][QtCore][QSocketNotifier] Added QSocketNotifier::activated(QSocketDescriptor, QSocketNotifier::Type). This replaces the activated(int) signal which in 64-bit environments could truncate the socket descriptor. If you use "activated" with the string-based connect() then you need to update the parameter type of the signal and slot if it had one. If you use it with the pointer to member function based connect() then all you need to do is update your slot's parameter type if it has one. If you need to compile your source code with multiple versions of Qt then connect() to this function using pointer to member function and update the slot's parameter type if needed. Task-number: QTBUG-70441 Change-Id: Ic43d6bc4c5bcb4040867b2ffad8d36fb01eed8af Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* QProcess/Linux: use the FFD_VFORK_SEMANTICS flagThiago Macieira2020-03-251-3/+10
| | | | | | | | | | | | | | ... when we are not using the FFD_USE_FORK flag. We use the FFD_USE_FORK flag when we have user code to run in setupChildProcess(). This code is enabled for all Unix, but forkfd() honors this flag only on Linux >= 5.4. See the commit adding the flag for more information on what the flag does and see the comment in this commit on why it's safe to use it. Fixes: QTBUG-17331 Change-Id: I1bee3bc466a04f19bd6efffd15f448cb23ce1e91 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
* QProcess: use FFD_USE_FORK when the class is not QProcess itselfThiago Macieira2020-01-091-1/+6
| | | | | | | | | | | | | | | | If the user derived from QProcess, it's likely to override the setupChildProcess() virtual. Unlike fork(), the system calls for enhenced functionality (FreeBSD pdfork() and Linux's clone()) won't call pthread_atfork() callbacks and the environment in the child process could be inconsistent. Qt's own code is safe, but we can't make the same statement about users' code. So we err on the safe side for correctness and run the old, less safe implementation (thread-unsafe, subject to hijacking of the signal handler, etc.). Change-Id: Ia2aa807ffa8a4c798425fffd15d9703bd03f6f09 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Tidy nullptr usageAllan Sandfeld Jensen2019-12-061-12/+12
| | | | | | | | | | | Move away from using 0 as pointer literal. Done using clang-tidy. This is not complete as run-clang-tidy can't handle all of qtbase in one go. Change-Id: I1076a21f32aac0dab078af6f175f7508145eece0 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Make QObjectPrivate::threadData a proper atomicGiuseppe D'Angelo2019-11-131-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QObjectPrivate::threadData used to be a QThreadData *, and was read and written from multiple threads without proper synchronization. As an example, it was read from QCoreApplication::postEvent and written from QObject::moveToThread, therefore causing UB. Port threadData to a proper atomic, removing the races. Fix all usage points. In general, QObject is documented to be simply reentrant, not thread-safe, and certain bits (e.g. timers, moveToThread) are not even reentrant. The reasoning therefore is that a given QObject's threadData is not supposed to be touched by multiple threads without some synchronization happening elsewhere, and therefore relaxed loads should be sufficient. As drive-by change: refactor QCoreApplication::postEvent. It was particularly subtle, because it had a loop using a volatile to cope with the possibility of the receiver object switching thread while we tried to lock its thread's event queue. However, volatile does not achieve any synchronization, so drop it, and refactor the algorithm using better locking primitives. Put this algorithm in a common place, and also reuse it from removePostedEvents, which was lacking any synchronization. Change-Id: Icc755f7eb418ff54b33db4bdd87fd8eaf4e82c7a Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* QtCore: port all QMutexLocker users to qt_{scoped,unique}_lockMarc Mutz2019-08-251-1/+2
| | | | | | | | | | | | | | | | ... except four instances in QCoreApplication that would conflict with another change. Replace a locally-defined MutexUnlocker with a call to unlock() + qScopedGuard'ed lock() to avoid having to spell out the locker type while we can't depend on C++17 CTAD, yet. In QSettings, move the new mutex locker into and out of initDefaultPaths(), such as is idiomatic for std::unique_lock, but wasn't possible with QMutexLocker (which is not movable). Change-Id: I23056e13ecaa76159db583c7dccc6e05715e0788 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* QProcessEnvironment: simplify lockingMarc Mutz2019-07-161-2/+0
| | | | | | | | | | | | | | | | The mutex is only protecting 'nameMap'. Proof: it's only defined on platforms on which there is a 'nameMap'. Also, nothing else is mutable, so no lazy init going on here. So, drop all the mutex protection, except where we access 'nameMap', and draw the mutex as close as possible to the nameMap uses, iow: copy ctor, prepareName() and nameToString(). As a consequence, the old (Ordered)MutexLocker class only needs to be defined on Unix. Change-Id: Ic969313bc48ad7ebf24c5dca7fd48359956b048d Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Port from implicit to explicit atomic pointer operationsMarc Mutz2019-06-291-1/+1
| | | | | | | | | | | | The old code used the implicit conversions from QAtomicPointer<T> to T* and vice versa. The semantics of these differ from the ones std::atomic uses, so we're going to deprecate these, like we did for load() and store(), too. This patch fixex some users of these APIs before we deprecate them. Change-Id: I0a88bb1c359392538bb64b511bfc62381a56a468 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* corelib/io: use qUtf16Printable(), %ls, qErrnoWarning()Marc Mutz2019-05-291-4/+3
| | | | | | | | | | | | | ... instead of qPrintable(), %s, explicit qt_error_string(). Saves temporary QByteArray creation, and 540b in text size on optimized Linux AMD64 GCC 9.1 builds. Change-Id: Id4e861683cf05a92faf51e4a9de9eb1dec4fc84a Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Modernize the "thread" featureUlf Hermann2018-08-171-1/+0
| | | | | | | | | | Add it to configure.json and replace all occurrences of QT_NO_THREAD with QT_CONFIG(thread). Add conditions for other features that depend on thread support. Remove conditions where we can use the QMutex and QThreadStorage stubs. Change-Id: I284e5d794fda9a4c6f4a1ab29e55aa686272a0eb Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
* Fix conditions for dup2 in QProcess::startDetachedJoerg Bornemann2018-08-011-7/+5
| | | | | | | | | | | The channel pipes are only set up if the channel's type is Redirect. Fix the conditions accordingly. This amends commit 7ad55ca6. Change-Id: Ie8a800fbe2bf9f5f6709b14ba03133b80e9b4bef Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
* qprocess: don't leak pid pipe if redirection fails in startDetached()Oswald Buddenhagen2018-05-301-0/+2
| | | | | Change-Id: Ifc42f634964b9412f73f53fb20bd220fcbd9a86c Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Replace Q_NULLPTR with nullptr where possibleKevin Funk2017-09-191-1/+1
| | | | | | | | | | | | | Remaining uses of Q_NULLPTR are in: src/corelib/global/qcompilerdetection.h (definition and documentation of Q_NULLPTR) tests/manual/qcursor/qcursorhighdpi/main.cpp (a test executable compilable both under Qt4 and Qt5) Change-Id: If6b074d91486e9b784138f4514f5c6d072acda9a Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
* Merge remote-tracking branch 'origin/5.9' into devLiang Qi2017-08-311-0/+12
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: examples/examples.pro qmake/library/qmakebuiltins.cpp src/corelib/global/qglobal.cpp Re-apply b525ec2 to qrandom.cpp(code movement in 030782e) src/corelib/global/qnamespace.qdoc src/corelib/global/qrandom.cpp src/gui/kernel/qwindow.cpp Re-apply a3d59c7 to QWindowPrivate::setVisible() (code movement in d7a9e08) src/network/ssl/qsslkey_openssl.cpp src/plugins/platforms/android/androidjniinput.cpp src/plugins/platforms/xcb/qxcbconnection.cpp src/plugins/platforms/xcb/qxcbconnection_xi2.cpp src/widgets/widgets/qmenu.cpp tests/auto/widgets/kernel/qwidget_window/tst_qwidget_window.cpp Change-Id: If7ab427804408877a93cbe02079fca58e568bfd3
| * QProcess/Unix: fix possible race condition inside waitForXXX() loopsAlex Trotsenko2017-08-181-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Calling QCoreApplication::processEvents() from a slot connected to the readyRead() signal might cause desynchronization in the waitForXXX() loop, if the process has been finished during the event processing. This results in unnecessary timeouts and causes waitForFinished() to fail unexpectedly. So, a proposed solution is to check the state on each iteration of the loop, as Windows implementation does. Given issue is tested by tst_QProcess::processEventsInAReadyReadSlot() which was unstable in CI. Task-number: QTBUG-62584 Change-Id: I7438cf67b0163bbf49314008a9dc660c0977fb7b Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Merge remote-tracking branch 'origin/5.9' into devLiang Qi2017-07-041-27/+19
|\| | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/io/qprocess_unix.cpp src/plugins/platforms/xcb/qxcbconnection.cpp src/plugins/platforms/xcb/qxcbwindow.cpp src/widgets/util/util.pri tests/auto/corelib/thread/qthread/qthread.pro tests/auto/corelib/thread/qthread/tst_qthread.cpp Change-Id: I5c45ab54d46d3c75a5c6c116777ebf5bc47a871b
| * QProcess/Unix: move strerror() up from child to parentThiago Macieira2017-06-281-27/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In theory, there's nothing wrong with having it in the child process. In practice, we've found that strerror/malloc can hang: if an application- wide lock was held by another thread before fork(), the child process could wait forever for an unlocking that will not happen (no threads running). See https://sourceware.org/bugzilla/show_bug.cgi?id=19431 As an added bonus, we now use qt_error_string(), which may produce slightly different text from strerror. [ChangeLog][QtCore][QProcess] Added a workaround for a rare race- condition bug in some C libraries that caused the child process started by QProcess to hang after trying to launch a non-existent executable or change to a non-existent directory. Task-number: QTBUG-61634 Change-Id: I1eba2b016de74620bfc8fffd14cbce4b9f9af69b Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-21 15:13:48 +0000