summaryrefslogtreecommitdiffstats
path: root/src/network
Commit message (Collapse)AuthorAgeFilesLines
* Merge remote-tracking branch 'origin/5.13' into devQt Forward Merge Bot2019-08-161-2/+4
|\ | | | | | | Change-Id: Ia3645f92b9debf3e1fe2d972300c7d0dbd649268
| * Merge remote-tracking branch 'origin/5.12' into 5.13Qt Forward Merge Bot2019-08-151-2/+4
| |\ | | | | | | | | | Change-Id: Id7954ada1f8658d3b1da5e8241a09f2d201a7c56
| | * Make our connection-level window half of a possible maximumTimur Pocheptsov2019-08-141-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some servers seem to be unable to properly calculate our window size from a delta we send via WINDOW_UPDATE frame immediately after our client preface and the SETTINGS frame. The remote replies with a GOAWAY frame blaming flow control error. Guessing what's this magic number they use seems to be not feasible, we now use a half of what we had before. Fixes: QTBUG-77308 Change-Id: I41dacfd25a395a27003f330d01b6d8d60b8f407c Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
| * | Merge remote-tracking branch 'origin/5.12' into 5.13Liang Qi2019-08-051-6/+6
| |\| | | | | | | | | | | | | | | | | | | | | | Conflicts: qmake/generators/unix/unixmake2.cpp src/plugins/platforms/cocoa/qcocoawindow.mm Change-Id: Iba7aa7324f35543e0297a3680956420058cd3630
| | * Plug a memory leak introduced in e24a4976bebd7ca90deac2b40c08900625773Volker Hilsheimer2019-07-311-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While it is correct not to call the functor when the context object has been destroyed, we still need ot clean up the slotObj. It's a low- probability memory leak: the context object has to disappear while waiting for a host resolution, and for repeated requests for the same host the cache takes over anyway. Task-number: QTBUG-76276 Change-Id: Id9daf391353b8252443f3186a7d504d70c553b24 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | | QNetworkConnectionMonitor: Fix compilation with older Windows KitsFriedemann Kleint2019-08-131-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove "final" since it has problems with 10.0.15063.0: qnetconmonitor_win.cpp C:\Program Files (x86)\Windows Kits\10\include\10.0.15063.0\winrt\wrl/client.h(61): error C3246: 'Microsoft::WRL::Details::RemoveIUnknownBase<T>': cannot inherit from 'QNetworkConnectionEvents' as it has been declared as 'final' with [ T=QNetworkConnectionEvents ] kernel\qnetconmonitor_win.cpp(102): note: see declaration of 'QNetworkConnectionEvents' kernel\qnetconmonitor_win.cpp(373): note: see reference to class template instantiation 'Microsoft::WRL::Details::RemoveIUnknownBase<T>' being compiled with [ T=QNetworkConnectionEvents ] C:\Program Files (x86)\Windows Kits\10\include\10.0.15063.0\winrt\wrl/client.h(61): error C3246: 'Microsoft::WRL::Details::RemoveIUnknownBase<T>': cannot inherit from 'QNetworkListManagerEvents' as it has been declared as 'final' with [ T=QNetworkListManagerEvents ] kernel\qnetconmonitor_win.cpp(468): note: see declaration of 'QNetworkListManagerEvents' kernel\qnetconmonitor_win.cpp(650): note: see reference to class template instantiation 'Microsoft::WRL::Details::RemoveIUnknownBase<T>' being compiled with [ T=QNetworkListManagerEvents ] Change-Id: Ia35545b65acaebea3fcff194884be8a156974123 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* | | Short live qt_unique_lock/qt_scoped_lock! (until C++17)Marc Mutz2019-08-132-34/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that QRecursiveMutex is getting split off of QMutex, QMutexLocker will stop working on QRecursiveMutex once the split has been finalized in Qt 6. Even today, QMutexLocker contains casts from QBasicMutex to QMutex that some reviewers are uncomfortable with. One way to carry QMutexLocker forward is to template it on the mutex type, possibly with aliases like QBasicMutexLocker and QRecursiveMutexLocker. C++17 code would then not require a port, thanks to CTAD. But we have the problem now, and we can't template QMutexLocker in Qt 5. The alternative is to look at std and realize that they have surpassed QMutexLocker in expressiveness already. A scoped_lock cannot be unlocked again, a unique_lock can be moved around. QMutexLocker doesn't do either. The only "problem" is that the std lock classes are already templates, but we can't, yet, rely on C++17 CTAD to make them look as if they weren't. So, prepare for a future with C++17 CTAD by writing factory functions, qt_scoped_lock and qt_unique_lock, which will later port mechanically to their C++17 equivalents (mostly). The functions are added to a new private qlocking_p.h becauee we don't want to make them public. These are for use in Qt's own implementation, or for users that don't care about compatibility and will not mind them to be removed once we depend on C++17. Originally, I planned to use qmutex_p.h instead, but that header is not self-contained and causes build errors when we started to include it into libraries other than QtCore. Regarding the return value of qt_scoped_lock: Ideally, we'd like to return a std::scoped_lock, but two things stand in the way: First, scoped_lock was only added in C++17 (we fall back to lock_guard if scoped_lock is not available). Second, returning one from a function requires C++17 guaranteed copy elision, because neither scoped_lock not lock_guard have a copy ctor. In order for code not to come to depend on a particular lock class, we return any of lock_guard, unique_lock or scoped_guard, depending on what the compiler supports, and therefore wrap the functions in the unnamed namespace to avoid running into ODR if (private) headers are used from different projects (autotests, e.g.). By the time we can drop them, however, qt_*_lock will be semantically 100% identical to their replacements. Port some initial users. Change-Id: I2a208ef2a4a533ee8e675812273986460e6b4d00 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | | Refactor memory allocation for arguments of QMetaCallEventsVolker Hilsheimer2019-08-101-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two cases: In a BlockingQueuedConnection, QMetaCallEvent doesn't allocate memory and instead passes already existing pointers through. A QSemaphore is used to serialize data access between threads. So the constructor taking a QSemaphore can be simplified to only accept an existing arg array. In a QueuedConnection, QMetaCallEvent needs to make deep copies of the arguments, and memory needs to be allocated based on the number of arguments. The previous code put the burden of memory allocation on the code generating the event, while the memory was free'd by ~QMetaCallEvent. Instead, make it QMetaCallEvent's responsibility to allocate and free the memory as needed, and adjust the code generating QMetaCallEvents. We can allocate the memory for types and pointers to arguments in a single block, starting with the space for the array of void*, followed by the space for the array of integers to avoid byte alignment issues. By pre-allocating the space that's needed by three arguments, we can avoid all mallocs for the majority of QMetaCallEvents. Until this change has propagated through qt5.git, we need to keep the old API that is still used by QtDeclarative around. Once QtDeclarative has migrated to the new API, it can be removed. Change-Id: Id7359ffc14897237ea9672dabae9ef199a821907 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* | | Unify and simplify the QHostInfo::lookupHost overloadsVolker Hilsheimer2019-08-072-127/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The three cases - with classic slot, with functor and context object, and with lambda - are all doing the same work, they just differ in how they signal the application code about the results. The detour through an explicitly posted QMetaCallEvent is needed if we have a functor or lambda; making sure that the temporary QHostInfoResult object lives in the right thread guarantees that the event is received in the correct thread, so we can directly call the functor (as long as the context object is still alive). Since we guarantee that the QHostInfoResult object lives in the thread of the receiver, we can simply emit the signal for old-style signal/slot connections; the regular signal/slot mechanism will do the work for us. Change-Id: I584df17df879af01c653e354490c4691dbedd3fa Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | | Fix spdy build without features.propertiesTasuku Suzuki2019-08-012-4/+13
| | | | | | | | | | | | | | | | | | | | | Move location of stream ID from a dynamic property to an internal QHash. Change-Id: I9bab4cbfaebe6a04d54afa7889aac748070e1f2e Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | | Merge remote-tracking branch 'origin/5.13' into devLiang Qi2019-07-304-12/+70
|\| | | | | | | | | | | | | | | | | | | | Conflicts: qmake/generators/win32/mingw_make.cpp Change-Id: I2f790bc8572bd22fea01edf7ca74595b29f063eb
| * | Merge "Merge remote-tracking branch 'origin/5.12' into 5.13"Qt Forward Merge Bot2019-07-293-10/+66
| |\ \
| | * | Merge remote-tracking branch 'origin/5.12' into 5.13Qt Forward Merge Bot2019-07-293-10/+66
| | |\| | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/io/qresource.cpp Change-Id: I54917f72444a621bd08aeaa15f5d17415993144d
| | | * QHostInfo: Always post results through the event loop to the receiverVolker Hilsheimer2019-07-262-10/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Lookups performed via QHostInfoRunnable must not synchronously call the user-code's receiver objects, as that would execute user-code in the wrong thread. Instead, post a metacall event through the event loop of the receiver object, or the thread that initiated the lookup. This was done correctly for the trivial cases of empty host name or cached results, so the code generally existed. By moving it from a global function into a member function of QHostInfoResult, we can simply access the required data to construct and post the event. As we process that posted event, we need to check that the context object (which is already guarded via QPointer) is still alive, if we had one in the first place. If we had one, and it's deleted, then abort. [ChangeLog][QtNetwork][QHostInfo] Functors used in the lookupHost overloads are now called correctly in the thread of the context object. When used without context object, the thread that initiates the lookup will run the functor, and is required to run an event loop. Change-Id: I9b38d4f9a23cfc4d9e07bc72de2d2cefe5d0d033 Fixes: QTBUG-76276 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
| | | * Android: Fix SSL 1.1 support on API-21BogDan Vatra2019-07-261-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OpenSSL 1.1.x libs must be suffixed otherwise it will use the system ones which on API-21 are OpenSSL 1.0 not 1.1 Fixes: QTBUG-76884 Change-Id: I7d4052be68cf7dc65f74a48da8e1e37182056a5e Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
| * | | wasm: fix wide character data downloadLorn Potter2019-07-291-2/+4
| |/ / | | | | | | | | | | | | | | | | | | | | | Need to pass correct buffer size Change-Id: I19cb65114f49decc225cd807d59f1f08ad6b70c9 Fixes: QTBUG-76212 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* | | Port from QStringViewLiteral to u""Marc Mutz2019-07-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Now that all our supported compilers know char16_t, we no longer need QStringViewLiteral, whose only purpose in life was to turn u"" into L"" for MSVC < 2015. Change-Id: I25a094fe7992d9d5dbeb4a524d9e99e043dcb8ce Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* | | Merge remote-tracking branch 'origin/5.13' into devQt Forward Merge Bot2019-07-273-18/+52
|\| | | | | | | | | | | Change-Id: Ic6cfe08dbda1dc92b969e67063f805df63ba0fcf
| * | Merge remote-tracking branch 'origin/5.12' into 5.13Liang Qi2019-07-263-18/+52
| |\| | | | | | | | | | | | | | | | | | | Conflicts: src/network/access/qhttpthreaddelegate.cpp Change-Id: Id47b977587e2d713c16ac17e63c5ec80c2f05ee9
| | * Implement 'preconnect-https' and 'preconnect-http' for H2Timur Pocheptsov2019-07-243-18/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QNetworkAccessManager::connectToHostEncrypted()/connectToHost() creates 'fake' requests with pseudo-schemes 'preconnect-https'/ 'preconnect-http'. QHttp2ProtocolHandler should handle this requests in a special way - reporting them immediately as finished (so that QNAM emits finished as it does in case of HTTP/1.1) and not trying to send anything. We also have to properly cache the connection - 'https' or 'http' scheme is too generic - it allows (unfortunately) mixing H2/HTTP/1.1 in a single connection in case an attribute was missing on a request, which is wrong. h2c is more complicated, since it needs a real request to negotiate the protocol switch to H2, with the current QNetworkHttpConnection(Channel)'s design it's not possible without large changes (aka regressions and new bugs introduced). Auto-test extended. Fixes: QTBUG-77082 Change-Id: I03467673a620c89784c2d36521020dc9d08aced7 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* | | QHostInfo: un-QObject-ify QHostInfoLookupManagerMarc Mutz2019-07-192-9/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QObjects are not even reentrant, but this class must be thread-safe, so it's always ... icky ... to have to analyze a "thread-safe QObject", because for all intents and purposes, that's an oxymoron. The QObject-ness isn't even used, except for defining a private slot, connected to QCoreApplication::destroyed(). That slot just calls waitForDone() on QThreadPool, which is a QObject itself, so use it as the context object for the signal-slot connection, using a lambda as slot. So, strip the class of it's base class, convert the private slot to a lambda and connect to that. Finally, remove the moveToThread() call, because this new class can be destroyed from any thread, not just the main one. Change-Id: I0e33983aa7afd0ad621ece4afd10d9e4adad38c1 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* | | QHostInfo: remove unused QAbstractHostInfoLookupManagerMarc Mutz2019-07-192-29/+10
| | | | | | | | | | | | | | | | | | | | | | | | If it was used in the past, it no longer is, and can't be, because it's not exported. Change-Id: Ifb9c353e756add5b57bf0c5706c075bb2eb41d83 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | | QSharedNetworkSessionManager: prune expired QNetworkSessionsMarc Mutz2019-07-191-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Equality for QNetworkConfiguration is defined by identity of the Private object, so even if there are QNCs with the same properties, they will not compare equal. This probably happens when a user roams through different WLANs (e.g. from work via public transport to home and then back), and each time the home WLAN pops up, it will beget a new QNetworkConfiguration, not comparing equal to the previous one. So, over time, we might collect a sizeable amount of QNetworkConfiguration objects just sitting in the cache without ever being able to actually use an associated network session, because they all have long since expired. To fix, prune expired network sessions, and thus their associated QNetworkConfigurations, from the cache. To not run every time, prune only when this size of the cache is larger than 16 (arbitrary number). Change-Id: I11a636f45ccf67420f84b1c79a4453a144de7c5c Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* | | Merge remote-tracking branch 'origin/5.13' into devQt Forward Merge Bot2019-07-191-1/+1
|\| | | | | | | | | | | Change-Id: I999ba23a27cd897017d15c6ffe41ea8cd008ffb9
| * | Merge remote-tracking branch 'origin/5.12' into 5.13Qt Forward Merge Bot2019-07-181-1/+1
| |\| | | | | | | | | | Change-Id: I685000c4f33fb3707b2102fae0b58092107dc8f0
| | * QHttpSocketEngine: The 'Connection' options are case insensitiveMårten Nordheim2019-07-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As noted in RFC7230 Section 6.1 the 'Connection' options are case insensitive. https://tools.ietf.org/html/rfc7230#section-6.1 Change-Id: I80b98d82eaa5572d38a6c3f99383bc059ec91c54 Fixes: QTBUG-76990 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | | QHostInfo: port from recursive to non-recursive mutexMarc Mutz2019-07-182-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out that the only reason a recursive mutex is used was because work() was locking it. But work() was only ever called from functions that already had locked the mutex themselves, and kept it locked across the call to work(). Clearly mark work() as expecting to be called with the mutex held (by renaming the function to rescheduleWithMutexHeld(), then drop the mutex locking from it. After this change, a non-recursive mutex suffices, so save the memory allocation and extra complexity involved with recursive mutexes. Looking at the non-QT_CONFIG(thread) code in rescheduleWithMutexHeld(), one might be tempted to expect a recursive mutex, since that code calls QHostInfoRunnable::run() directly, which, in turn, recurses into QHostInfoLookupManager whence control came, under mutex lock. But in non-QT_CONFIG(thread) builds, QMutex is but an empty shell, all of its operations are no-ops, so no possibility for deadlock, either. Change-Id: Ic01d90c2ed3995b66ccf946d146fdaa6f9af3d8b Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* | | QHostInfo: add nothrow move constructorMarc Mutz2019-07-182-5/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QHostInfo isn't implicitly shared. The more important to optimize away copies by providing a move constructor. Port from QScopedPointer to Q_DECLARE_PRIVATE, as otherwise the move ctor can't be inline, and we don't implement move ctors out-of-line in Qt. [ChangeLog][QtNetwork][QHostInfo] Added move contructor. Change-Id: I6b63a04e36f63e299205830fdc590ff7e2af338b Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | | QtNetwork: ssl: port from QMutex::Recursive to QRecursiveMutexMarc Mutz2019-07-183-3/+3
| | | | | | | | | | | | | | | Change-Id: I78913fee6720f6ad9b196824b35de189567340be Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | | Merge "Merge remote-tracking branch 'origin/5.13' into dev"Qt Forward Merge Bot2019-07-173-84/+74
|\ \ \
| * | | Merge remote-tracking branch 'origin/5.13' into devQt Forward Merge Bot2019-07-173-84/+74
| |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: src/corelib/global/qlogging.cpp src/gui/painting/qtextureglyphcache_p.h src/gui/text/qfontengine.cpp src/widgets/widgets/qlineedit.cpp Change-Id: Ic8798538df466b7141caa8bbf1fb7605eb56be37
| | * | Merge remote-tracking branch 'origin/5.12' into 5.13Qt Forward Merge Bot2019-07-123-84/+74
| | |\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: configure.pri Also required s/solid\.color/solidColor/ in a couple of places in: src/gui/painting/qpaintengine_raster.cpp Change-Id: I29937f63e9779deb6dac7ae77e2948d06ebc0319
| | | * Windows: handle errors correctly when connecting to unreachable hostVolker Hilsheimer2019-07-111-60/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous code handled only some error codes, in a very inefficient way, for some code paths. This change standardizes error handling using a helper function that maps winsock WSAE* codes to Qt error codes. The test for connecting to unreachable hosts or ports is now more generic, and enabled on Windows, where it passes in local tests, but dependency on network configuration still makes it fragile, so ignoring some failures without completely skipping the test. [ChangeLog][Network][Windows] Correctly emit errors when trying to reach unreachable hosts or services Change-Id: Icaca3e6fef88621d683f6d6fa3016212847de4ea Fixes: QTBUG-42567 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
| | | * QHostInfo: fix a race condition on QHostInfoCache::enabledMarc Mutz2019-07-092-17/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In auto-test-enabled builds, QHostInfoCache can be enabled and disabled using qt_qhostinfo_enable_cache() at any time. We cannot rule out that users use this function, or, indeed, that the auto-test never gets a threading stress-test. Under the assumption, then, that QHostInfoCache::enabled can be set by any thread at any time, and is read by any thread using QHostInfo::lookupHost(), we're presented with a data race, thus UB. Fix by making the accesses to QHostInfoCache::enabed atomic. Relaxed operations are suffcient, as the bool is the only data of interest in these situations. In particular, access to the cache itself is protected by the cache's mutex. We use std::atomic<bool> because QAtomicInteger<bool> doesn't exist on all implementations, but std::atomic<bool> must. Commit a0faf9e2366 set the precedent that it works. Change-Id: Ia1766753bb54c5fe8d8447b51a49a96a7a853eef Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
| | | * QHostInfo: fix a race condition on wasDeletedMarc Mutz2019-07-051-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The plain bool variable wasDeleted is set to true in the QHostLookupManager dtor before the call to clear(), which calls waitForDone() on the thread pool performing the lookups. All tasks on the thread pool start by checking this variable so as to return early when destruction is in progress. But the check was outside the mutex-protected area, so as a non-atomic load, without a happens-before relation to the write, this is a Data Race, thus UB. Fix by moving the check past the mutex locking into the critical section. This way, tasks that were waiting for the mutex after seeing no wasDeleted before get the message reliably. This does not introduce a dead-lock, since the call to waitForDone() is outside any mutex protection leaving a window for the tasks to obtain the mutex and react on wasDeleted. Change-Id: Ied4b9daa7dc78295b0d36a536839845c4db2fb78 Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: David Faure <david.faure@kdab.com>
* | | | Win: qnetconmon: Use CoInitialize instead of CoInitializeExMårten Nordheim2019-07-171-2/+2
|/ / / | | | | | | | | | | | | | | | | | | | | | | | | Somehow I didn't test using QNetwork{Status,Connection}Monitor together with Gui. In qwindowstheme.cpp we call CoInitialize and as such we cannot use CoInitializeEx with a different thread mode. Change-Id: If4a4441cc2616371d8b7cda72cfad11187d8f153 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | | QNetworkRequest: make the default ctor implicitMarc Mutz2019-07-152-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As in QVarLengthArray (c34242c679aaea6ee1badf6c1e5f274f925f5f50), this will probably bite someone someday, so fix it before there's a bug report. Use ctor delegation to keep code size increase small. There's also the benefit that default-constructing a QNetworkRequest now no longer creates an expensive QUrl object just to destroy it unused again. Add an auto-test. Change-Id: I5ceb5402ca3946048d695244d1b1c36564a1e80a Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | | QNativeSocketEngine: disable sign-compare warning-turned-error on ClangMarc Mutz2019-07-131-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On the WASM platform, the macro CMDG_NEXTHDR, which is not under our control, emits a warning about comparing ulong and long with each other, which -Werror turns into an error: qnativesocketengine_unix.cpp:1004:24: error: comparison of integers of different signs: 'unsigned long' and 'long' [-Werror,-Wsign-compare] cmsgptr = CMSG_NXTHDR(&msg, cmsgptr)) { ^~~~~~~~~~~~~~~~~~~~~~~~~~ emsdk/emscripten/1.38.30/system/include/libc/sys/socket.h:286:44: note: expanded from macro 'CMSG_NXTHDR' __CMSG_LEN(cmsg) + sizeof(struct cmsghdr) >= __MHDR_END(mhdr) - (unsigned char *)(cmsg) \ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Fix by locally disabling the warning. Change-Id: Ia2ed4318b2ef679b84ac8544835d1e383568ccac Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | | qsslsocket_openssl_symbols.cpp: replace manual memory management with ↵Marc Mutz2019-07-101-51/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | std::unique_ptr Also fix the name mismatch between the Windows- and non-Windows versions of loadOpenSsl(), which, presumably, were caused by having two different return values, something easily fixed by defining a small struct instead of using a QPair. Some #ifdef'ery saved, and a lot of brittle deletes on early returns. Change-Id: I77440de2f6fa51759510506ff4ef51917eb5b3ea Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* | | QHostInfoRunnable: make the lookupFinished() call more robustMarc Mutz2019-07-091-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Use a scope guard to reliably mark the runnable as finished with the manager, lest a deleted runnable lingers in the manager's currentLookups for too long/ever. Change-Id: I89eff49931d0428f4e75789a0a1188edb1f66220 Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* | | QHostInfo: perform deferred cleanup (std::any_of)Marc Mutz2019-07-081-8/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | The code contained a copy of std::any_of from a time when we couldn't rely it's availability in all compilers. We now can, so remove the copy. Change-Id: I356077f58ae6a48b71f2dd98a2dab4e2acf985c7 Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru> Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* | | Add manual test for QNetwork{Connection|Status}MonitorMårten Nordheim2019-07-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Simplistic console application with one test for each of the two classes. Simply tests that we receive the signal when the connection is disrupted in some way. This patch also exports the classes for tests/developer builds so that we can actually link with them. Change-Id: I8066312274350984110c3f3ad3e94854adca7c2a Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* | | qnetconmonitor: Fix misspelling of accessibleMårten Nordheim2019-07-085-8/+8
| | | | | | | | | | | | | | | Change-Id: Ia898d305f64abb5d3d1de007c764c143b26c7654 Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | | Introduce QNetwork(Connection|Status)Monitor to WindowsMårten Nordheim2019-07-083-0/+735
| | | | | | | | | | | | | | | | | | | | | | | | Currently not available for mingw because it's missing all the interfaces. But should start working once it has them. Change-Id: I231e8b69e008c5300a83087fe9cd071acd0687cb Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | | QNAM: Don't condition connecting QNetworkReplyImpl signals on qnetconmonMårten Nordheim2019-07-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | QNetwork{Status,Connection}Monitor isn't used for QNetworkReplyImpl yet, so we should connect the signal until it is. Change-Id: I40f1483608195418d43c442f46184882f64596ff Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | | Inline QMutexPool into its only remaining userMarc Mutz2019-07-081-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Also reduce the pool size from 131 to 17, and use QBasicMutex instead of recursive ones. Change-Id: I3bf0374cce5ff2c07427070aba6128a22c9b70e4 Reviewed-by: Lars Knoll <lars.knoll@qt.io> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io> Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* | | qsslsocket_openssl_symbols.cpp: replace mutex pool use with QBasicMutexMarc Mutz2019-07-081-14/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The use of QMutexPool caused an #ifdef, because, lacking an object, some OpenSSL function pointer was used as the address required as input for the mutex pool. Sadly, the names of the functions differ between OpenSSL versions, thus the need for an #ifdef. By simply using a QBasicMutex (defined at namespace scope to evade https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79561), the #ifdef can go away. Another level of #ifdefs goes away because, even for non-QT_CONFIG(thread) builds, Q*Mutex etc are defined, just as no-ops. So we can freely use them without QT_CONFIG(thread) guard, unlike QMutexPool. Finally, optimize for the (common?) case of already-loaded libraries by making symbolsResolved an atomic variable, and checking that before taking the mutex (double-checked locking, done right). For reasons of said GCC bug, again, the QBasicAtomic is defined at namespace scope. And then move the other boolean there for symmetry. Change-Id: Ic5f44871fb200e5368b9af327e4d1e852fbc586c Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* | | QtNetwork: port remaining uses of QMutex::Recursive to QRecursiveMutexMarc Mutz2019-07-065-11/+8
| | | | | | | | | | | | | | | | | | | | | In one case, added NSDMI to avoid churning the ctor-init-list. Change-Id: I5587d5cb7e393f60ad29cb5186127304d27d1d46 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* | | QtNetwork: bearer: port from QMutex::Recursive to QRecursiveMutexMarc Mutz2019-07-066-8/+7
| | | | | | | | | | | | | | | | | | Change-Id: I691ecbaf9ea0796decbb48fd62b25d0a2941d979 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
* | | Merge "Merge remote-tracking branch 'origin/5.13' into dev"Liang Qi2019-07-053-12/+22
|\ \ \