summaryrefslogtreecommitdiffstats
path: root/src/corelib/io/qprocess_unix.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* | Merge remote-tracking branch 'origin/5.9' into devLiang Qi2017-06-191-7/+7
|\| | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/io/qprocess_unix.cpp src/corelib/io/qprocess_win.cpp src/plugins/platforms/android/qandroidplatformintegration.h src/plugins/platforms/windows/qwindowscontext.cpp src/plugins/platforms/windows/windows.pri src/tools/uic/cpp/cppwriteinitialization.cpp src/widgets/doc/src/widgets-and-layouts/gallery.qdoc Change-Id: I8d0834c77f350ea7540140c2c7f372814afc2d0f
| * Use QMap in QProcessEnvironment so variables are sortedThomas Sondergaard2017-06-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The motivation for this change is to make it simple to pass a correctly sorted environment block to Win32 CreateProcess(). It is also nice in other contexts that the environment variables are sorted. The change is made for all platforms. This keeps it simple and the only ill effect is slightly slower lookups. Concerning the environment block passed to Win32 CreateProcess: The environment block that is passed to CreateProcess() must be sorted case-insensitively and without regard to locale. See https://msdn.microsoft.com/en-us/library/windows/desktop/ms682009(v=vs.85).aspx The need for sorting the environment block is also mentioned in the CreateProcess() documentation, but with less details: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx Task-number: QTBUG-61315 Change-Id: Ie1edd443301de79cf5f699d45beab01b7c0f9de3 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
| * Rename QProcessEnvironmentPrivate::hash to varsThomas Sondergaard2017-06-131-4/+4
| | | | | | | | | | | | | | | | | | Also use auto for iterators to vars. This is a small refactoring in preparation for changing type of vars to QMap. Task-number: QTBUG-61315 Change-Id: I5731d7916b6f54a0da5be2da378c09a7688bd870 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Support standard channel redirection in QProcess::startDetachedJoerg Bornemann2017-06-131-0/+26
| | | | | | | | | | | | | | | | | | | | | | [ChangeLog][QtCore][QProcess] Added support for standard channel redirection using setStandard{Input|Output|Error}File to QProcess::startDetached. Task-number: QTBUG-2058 Task-number: QTBUG-37656 Change-Id: Iafb9bd7899f752d0305e3410ad4dcb7ef598dc79 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Merge remote-tracking branch 'origin/5.9' into devLiang Qi2017-04-201-0/+4
|\| | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/tools/qbytearray.h src/corelib/tools/qdatetime.h src/corelib/tools/qstring.h src/corelib/tools/qversionnumber.h src/plugins/platforms/android/qandroidplatformintegration.cpp tests/auto/corelib/tools/qhashfunctions/tst_qhashfunctions.cpp Change-Id: Iefd92a435e687a76cd593099e40d9a9620a1454d
| * QProcess: fix Unix buildJake Petroules2017-04-111-0/+4
| | | | | | | | | | | | | | | | This fixes a regression introduced in ff19ebcc Task-number: QTBUG-60046 Change-Id: I47c357433b25f07011a7a3a64d3150591785b206 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
* | QProcess::startDetached: support custom process environmentJoerg Bornemann2017-03-311-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Starting a detached process with a custom process environment can now be achieved by: QProcess p; p.setProgram("foo"); p.setProcessEnvironment(myEnv); p.startDetached(); [ChangeLog][QtCore][QProcess] Added the ability to set a custom process environment for detached processes. Task-number: QTBUG-2284 Change-Id: I49406dffb64fa2aed41ea05cb271bd42eeabb729 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Simplify Unix implementation of QProcess::start{Process|Detached}Joerg Bornemann2017-03-311-64/+27
| | | | | | | | | | | | | | | | Use QStandardPaths::findExecutable instead of duplicated implementations. Change-Id: Ia944f1d343d8c215fc2b6e78dae6b2bfffbba688 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Add non-static QProcess::startDetachedJoerg Bornemann2017-03-311-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | The three static QProcess::startDetached overloads support a limited number of features: program, arguments and working directory. To support more features of QProcess (without adding a plethora of overloads) we add a non-static method startDetached that can be used as follows: QProcess p; p.setProgram("cat"); p.setArguments("meow"); p.setWorkingDirectory("/tmp"); if (!p.startDetached()) qWarning("Cannot start process."); We plan to add support for nativeArguments, processEnvironment, standard{Output|Error}File and maybe more in subsequent commits. [ChangeLog][QtCore][QProcess] Added non-static QProcess::startDetached to support more features for detached processes. Task-number: QTBUG-2058 Task-number: QTBUG-2284 Task-number: QTBUG-37656 Task-number: QTBUG-52405 Task-number: QTBUG-57687 Change-Id: If6fdd57ecb28cd13aa5fff566216a4177f81d339 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
* Merge remote-tracking branch 'origin/5.8' into 5.9Liang Qi2017-03-131-3/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: examples/network/network.pro mkspecs/features/mac/default_post.prf src/corelib/io/qfilesystemengine_win.cpp src/corelib/io/qprocess.cpp src/corelib/io/qprocess.h src/corelib/io/qprocess_p.h src/corelib/io/qprocess_unix.cpp src/corelib/io/qprocess_win.cpp src/corelib/thread/qmutex.cpp src/platformsupport/fontdatabases/windows/windows.pri src/plugins/platforms/eglfs/eglfsdeviceintegration.pro tests/auto/corelib/io/io.pro Change-Id: I8a27e0e141454818bba9c433200a4e84a88d147e
| * Properly use the "process" featureUlf Hermann2017-02-271-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | Replace all QT_NO_PROCESS with QT_CONFIG(process), define it in qconfig-bootstrapped.h, add QT_REQUIRE_CONFIG(process) to the qprocess headers, exclude the sources from compilation when switched off, guard header inclusions in places where compilation without QProcess seems supported, drop some unused includes, and fix some tests that were apparently designed to work with QT_NO_PROCESS but failed to. Change-Id: Ieceea2504dea6fdf43b81c7c6b65c547b01b9714 Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
* | Make QProcessEnvironment available on Apple Platforms and VxWorksJake Petroules2016-12-161-13/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All Apple Platforms have public API to get the environment; there is no reason to exclude it from the UIKit subset. It can be useful for debugging in Xcode, in particular. Furthermore, VxWorks appears to have support for the Unix environment API, so don't exclude it either. [ChangeLog][QtCore] QProcessEnvironment is now available on iOS, tvOS, watchOS, and VxWorks Change-Id: Ife3745f9b0a588de521a714b4273c5c08eeef286 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* | Introduce a configure option for QProcessEnvironmentJake Petroules2016-12-161-33/+40
|/ | | | | | | | This decouples QProcess and QProcessEnvironment, since the latter may actually be available on platforms where the former is not. Change-Id: I3dc799ffdf94486b64143ed01a369897fff44a96 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Replace QCFString::to(CF/NS/Q)String usage with QString methodsTor Arne Vestbø2016-10-061-1/+1
| | | | | | | | Slims down QCFString and leaves only one implementation of converting back and forth between CF/NS strings and QStrings. Change-Id: I068568ffa25e6f4f6d6c99dcf47078b7a8e70e10 Reviewed-by: Jake Petroules <jake.petroules@qt.io>
* Add support for Apple tvOSMike Krus2016-05-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Pass -xplatform macx-tvos-clang to configure to build. Builds device and simulator by default. Added ‘uikit’ platform with the common setup. Also added QT_PLATFORM_UIKIT define (undocumented). qmake config defines tvos (but not ios). tvOS is 64bits only (QT_ARCH is arm64) and requires bitcode to be embedded in the binary. A new ‘bitcode’ configuration was added. For ReleaseDevice builds (which get archived and push to the store), bitcode is actually embedded (-fembed-bitcode passed to clang). For all other configurations, only using bitcode markers to keep file size down (-fembed-bitcode-marker). Build disables Widgets in qtbase, and qtscript (unsupported, would require fixes to JavaScriptCore source code). Qpa same as on iOS but disables device orientation, status bar, clipboard, menus, dialogs which are not supported on tvOS. Change-Id: I645804fd933be0befddeeb43095a74d2c178b2ba Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
* Merge remote-tracking branch 'origin/5.6' into 5.7Liang Qi2016-05-061-10/+25
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: examples/qtestlib/tutorial5/containers.cpp examples/widgets/tools/tools.pro src/corelib/io/qprocess.cpp src/corelib/io/qprocess_unix.cpp src/corelib/io/qprocess_win.cpp src/network/kernel/qdnslookup_unix.cpp src/plugins/platforms/xcb/qxcbconnection_xi2.cpp src/testlib/qtestcase.cpp tools/configure/configureapp.cpp Change-Id: I838ae7f082535a67a4a53aa13a21ba5580758be8
| * QWindowsPipeWriter: ensure validity of the write bufferAlex Trotsenko2016-04-301-10/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QWindowsPipeWriter uses asynchronous API to perform writing. Once a cycle has been started, the write buffer must remain valid until the write operation is completed. To avoid data corruption and possibly undefined behavior, this patch makes QWindowsPipeWriter::write() take a QByteArray, which it keeps alive for the duration of the write cycle. Autotest-by: Thomas Hartmann Task-number: QTBUG-52401 Change-Id: Ia35faee735c4e684267daa1f6bd689512b670cd2 Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
* | Merge remote-tracking branch 'origin/5.6' into 5.7Liang Qi2016-04-041-1/+1
|\| | | | | | | Change-Id: I35ca979395620e104e50b06366d0869433a4ffc2
| * Fix debug message to match the method's nameLorenz Haas2016-03-251-1/+1
| | | | | | | | | | Change-Id: Ieaf7366663beeecec3240353d045fb19e2ae99ee Reviewed-by: Louai Al-Khanji <louai.al-khanji@theqtcompany.com>
* | Merge remote-tracking branch 'origin/5.6' into 5.7Simon Hausmann2016-03-231-185/+0
|\| | | | | | | Change-Id: I9a10e1f3c9506ec8554d8f59b6300825ac730939
| * Remove QPROCESS_USE_SPAWN and all that it surroundsJames McDonnell2016-03-221-185/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The spawn code was only used to make QProcess work on QNX 6.5.0. Fork works on QNX 6.6.0. The QNX spawn implementation has a flaw that causes a deadlock in certain situations. When a working directory is specified for the process, the QNX spawn implementation stops all threads except the one doing the spawn so that it can temporarily change the process' working directory. This can lead to a deadlock if the thread does anything that conficts with something being done in a stopped thread. QNX 6.5.0 is no longer supported in Qt 5.6.0 so we can just switch QNX to the fork implementation and get rid of the spawn implementation. Made a QNX specific adjustment to the hardExit test. There's a bug in the OS that the test can run into because it does something that normal applications wouldn't. Task-number: QTBUG-47250 Change-Id: Ib32567d2c15ce651815858000035ac5aa6f35224 Reviewed-by: Dan Cape <dcape@qnx.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com> Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
* | QProcess: Remove dead codeLouai Al-Khanji2016-02-051-6/+0
| | | | | | | | | | | | | | | | These functions appear to have been dead code always - even in the earliest Qt4 releases! Change-Id: Ie2a458092b45113782284cf8ed3aa11a018b60d4 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Clean up new poll code slightlyLouai Al-Khanji2016-02-041-3/+3
| | | | | | | | | | Change-Id: I046126ff69a77a50e79efb1b6ebb0fffef67ac8e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | QProcess: Use poll instead of select on Unix platformsLouai Al-Khanji2016-02-031-89/+71
| | | | | | | | | | Change-Id: I3386ef228ce95209f6f221e18293d991b24a7b2e Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | Integrate QProcess into QIODevice's multistreaming infrastructureAlex Trotsenko2016-01-291-6/+6
| | | | | | | | | | | | | | | | As a result, this patch eliminates double-buffering in QProcess. Change-Id: I436faa4a5ffc28ce77f959dd6089bef400ac39f6 Reviewed-by: Allan Sandfeld Jensen <allan.jensen@theqtcompany.com> Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
* | Add Intel copyright to files that Intel has had non-trivial contributionThiago Macieira2016-01-211-0/+1
| | | | | | | | | | | | | | | | | | I wrote a script to help find the files, but I reviewed the contributions manually to be sure I wasn't claiming copyright for search & replace, adding Q_DECL_NOTHROW or adding "We mean it" headers. Change-Id: I7a9e11d7b64a4cc78e24ffff142b506368fc8842 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
* | Updated license headersJani Heikkinen2016-01-151-14/+20
| | | | | | | | | | | | | | | | | | | | | | From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/ Updated license headers to use new LGPL header instead of LGPL21 one (in those files which will be under LGPL v3) Change-Id: I046ec3e47b1876cd7b4b0353a576b352e3a946d9 Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-17 07:57:59 +0000