Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
As a drive-by, did also minor refactorings/improvements.
Task-number: QTBUG-98434
Change-Id: I81964176ae2f07ea63674c96f47f9c6aa046854f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Anton Kudryavtsev <antkudr@mail.ru>
After calling close(), the socket can enter 'Closing' state, in which
we try to write buffered data before disconnecting. As the device is
already closed, we must disable any pipe reader activity and clear the
read buffer.
Change-Id: I8994df32bf324325d54dd36cbe1a1ee3f08022d1
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
The base implementation discards the data by reading into a dummy
buffer, which is slower than necessary.
Change-Id: Iabf0c4a25746af6cac5b61d7bda66d89501c808c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
The base implementation reads data using repeated calls to getChar(),
which is quite slow.
Change-Id: Ie46624df63791b2cdd3c8a28fe3327427d942505
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
We can get better performance if we omit unlocking the mutex before
relocking it in startAsyncRead().
Change-Id: Ia012a71b95876d4f90c1dc4b7db5d7b267fca7a6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
An initial EOF check is not required here because the code below
correctly handles this case. Also, the condition '!pipeBroken' means
that the pipe reader is in the 'Running' state.
Change-Id: I608d932c4e38f8224d9e655272e61295e55414e0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
As a result, we can refrain from using the deleteLater() technique in
QProcess and avoid long-lived soft leaks in blocking applications.
Change-Id: I89e02b02551a668b995ad3d12d3ce9575b2dd9dd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
A delayed close should only be completed in the _q_bytesWritten() slot
as a confirmation of a successful write operation on the socket.
Otherwise, a failed write operation may cause the socket to be closed
unexpectedly within the waitFor...() function, which may result in a
malfunction.
Change-Id: I14cff26734f64a89090b6b5c13037466a6400597
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
[ChangeLog][QtNetwork][QLocalSocket] The waitFor*() functions on
Windows now support duplex operation, as they already did on Unix.
As a side effect, this restores the behavior that a single call to
waitForReadyRead() won't emit both readyRead() and disconnected(),
which also matches Unix behavior. The groundwork for that misbehavior
was laid by incorrect refactoring in d1a671b69 already, but at this
point it was harmless, as the pipe couldn't be newly closed after a
successful read. That changed with f265c87e0, which made the queuing
of signals async.
Change-Id: I1eb80e8f147bb58825143e0fe1e4300c59ae0fbb
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
For QProcess, there is no point in suppressing recursive
QWPR::readyRead() emission, as the former manages this logic itself. On
top of that, the non-recursive nature of QWPR::readyRead() indirectly
disallowed reading from the channels inside
QProcess::waitForReadyRead(), if that is called from a slot connected
to QProcess::readyRead().
QWPW had two signals, one allowing recursion and one not.
This commit allows recursion of QWPR::readyRead() and
QWPW::bytesWritten(), and moves recursion suppression to the higher-
level classes. This makes the code more uniform and efficient, at the
cost of a few duplicated lines.
Change-Id: Ib20017fff4d92403d0bf2335f1622de4aa1ddcef
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
These are internal APIs, so silence qdoc which seems to get confused
by the missing CALLBACK annotation in the implementation.
Change-Id: Iddd9f87257843cc3d43597fe7e6c103aa5e1a646
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Nico Vertriest <nico.vertriest@qt.io>
The 'pipeBroken' flag must be updated before emitting the readyRead()
signal to avoid deadlock of waitForReadyRead() inside slot connected
to readyRead().
Change-Id: Ie393fdd594c6691da6609ea18307589b7157c624
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Introduce QProcessPoller helper class on Windows that implements
waiting for any activity from a child process.
Change-Id: I99414db4424b4342e0fa3d7a3789f85cad76d190
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
When a foreign event loop that does not enter an alertable wait state
is running (which is also the case when a native dialog window is
modal), pipe handlers would freeze temporarily due to their APC
callbacks not being invoked.
We address this problem by moving the I/O callbacks to the Windows
thread pool, and only posting completion events to the main loop
from there. That makes the actual I/O completely independent from
any main loop, while the signal delivery works also with foreign
loops (because Qt event delivery uses Windows messages, which foreign
loops typically handle correctly).
As a nice side effect, performance (and in particular scalability)
is improved.
Several other approaches have been tried:
1) Using QWinEventNotifier was about a quarter slower and scaled much
worse. Additionally, it also required a rather egregious hack to
handle the (pathological) case of a single thread talking to both
ends of a QLocalSocket synchronously.
2) Queuing APCs from the thread pool to the main thread and also
posting wake-up events to its event loop, and handling I/O on the
main thread; this performed roughly like this solution, but scaled
half as well, and the separate wake-up path was still deemed hacky.
3) Only posting wake-up events to the main thread from the thread pool,
and still handling I/O on the main thread; this still performed
comparably to 2), and the pathological case was not handled at all.
4) Using this approach for reads and that of 3) for writes was slightly
faster with big amounts of data, but scaled slightly worse, and the
diverging implementations were deemed not desirable.
Fixes: QTBUG-64443
Change-Id: I66443c3021d6ba98639a214c3e768be97d2cf14b
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
... where it belongs.
To avoid the loop, introduce the drainAndStop() function, which allows
QWindowsPipeReader to flush the pipe itself. It determines the number of
bytes pending and blocks until the remainder of the process output is
received.
Note that the loop in drainOutputPipes() didn't actually have to
interleave the two pipes (because we're presuming that the operations
will finish instantly), so we don't do it now. Also, the code violated
the API contract: 'true' was returned when the 'wrong' channel received
data; this is now fixed as a side effect.
Change-Id: I38ed4861a238e39e793c3716e856e5bfdeed3d74
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
This reverts commit ee122077b0.
Reason for revert: This causes QProcess::readAll() to sometimes
return nothing after the process has ended.
Fixes: QTBUG-88624
Change-Id: I34fa27ae7fb38cc7c3a1e8eb2fdae2a5775584c2
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
(cherry picked from commit 23100ee61e33680d20f934dcbc96b57e8da29bf9)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When a foreign event loop that does not enter an alertable wait state
is running (which is also the case when a native dialog window is
modal), pipe handlers would freeze temporarily due to their APC
callbacks not being invoked.
We address this problem by moving the I/O callbacks to the Windows
thread pool, and only posting completion events to the main loop
from there. That makes the actual I/O completely independent from
any main loop, while the signal delivery works also with foreign
loops (because Qt event delivery uses Windows messages, which foreign
loops typically handle correctly).
As a nice side effect, performance (and in particular scalability)
is improved.
Several other approaches have been tried:
1) Using QWinEventNotifier was about a quarter slower and scaled much
worse. Additionally, it also required a rather egregious hack to
handle the (pathological) case of a single thread talking to both
ends of a QLocalSocket synchronously.
2) Queuing APCs from the thread pool to the main thread and also
posting wake-up events to its event loop, and handling I/O on the
main thread; this performed roughly like this solution , but scaled
half as well, and the separate wake-up path was still deemed hacky.
3) Only posting wake-up events to the main thread from the thread pool,
and still handling I/O on the main thread; this still performed
comparably to 2), and the pathological case was not handled at all.
4) Using this approach for reads and that of 3) for writes was slightly
faster with big amounts of data, but scaled slightly worse, and the
diverging implementations were deemed not desirable.
Fixes: QTBUG-64443
Change-Id: I1cd87c07db39f3b46a2683ce236d7eb67b5be549
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
This reverts commit c7ec07d401.
Reason for revert: This causes a memory leak on program termination.
The initial commit was an attempt to fix a deadlock where the user
destroys object from a thread that does not own the object. This is
an unsupported case and should be treated as an invalid report.
Pick-to: 5.15
Change-Id: I4957784b86a0361adb65b9d023542f96480f00ba
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
It is documented for the use, but we were rarely using it.
Change-Id: I812b9e6c8fbf204aba43ce2b79eca308ca75de88
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Replace by switch() where appropriate, remove else and unindent code
or simplify the return value.
Change-Id: Ie988b9068a9579ae5a899b3765e43aad480b564e
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
To read data from a named pipe, QWindowsPipeReader uses the ReadFileEx()
function which runs asynchronously. When reading is completed and the
thread is in an alertable wait state, the notified() callback is called
by the system, reporting a completion status of that operation. Then the
callback queues a readyRead signal and starts a new sequence. The latter
is skipped if the pipe is broken or the read buffer is full.
Thus, if an application does not run the event loop, the next call to
QWindowsPipeReader::waitForReadyRead() should emit the queued signal
and report true to the caller even if no new read operation was started.
Change-Id: I37102dbb1c00191d93365bfc2e94e743d9f3962a
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
A deadlock can occur if the user does
QLocalSocket *ls = new QLocalSocket;
ls->moveToThread(t);
...
delete ls;
Then QLocalSocket calls QWindowsPipeReader::stop() in a different thread
than the I/O operation is running in. The waitForNotified(-1) call would
then wait indefinitely until the I/O thread is in alertable wait state
again. Especially on application shut down this might never be the case,
and the application would deadlock.
Solve this by detaching the Overlapped object from the
QWindowsPipe{Reader|Writer} in stop() and delete it in the callback.
Task-number: QTBUG-61643
Change-Id: Ie262d75c5fd92ac7cf7dfcdbf1519050be9fd3c4
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
We forgot to update the warnings when removing qt_cancelIo.
Also, use %p instead of %x, because HANDLE is void*.
This amends commit fade2958.
Change-Id: Ia11d7d094aa6beb939e0be4bbe4ab3654eaa1c02
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
QRingBuffer::read() implements the same loop.
Change-Id: I480fe07e2400dfaee560f22bdbf07d6cdd013eb2
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
If the user calls QLocalSocket::setReadBufferSize() with a value less
than the current size of the pipe buffer, startAsyncRead() would call
ReadFileEx() with invalid parameters:
ReadFileEx(handle, nullptr, some_big_value, ...);
Change-Id: I3d153e3ec34f8038dc001c1c896aeceb666a8979
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We can now directly use CancelIoEx. The fallback to CancelIo
was needed for supporting Windows XP.
Change-Id: I24a53a774caf695e6006f24a914abaa5ab204035
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Re-work QWindowsPipeWriter to not use a thread anymore but the
WriteFileEx API, similar to QWindowsPipeReader. This saves us a lot of
thread synchronization code and enables us to directly write data
without yet another buffering layer.
Also, this fixes the dreaded deadlocks in the QWindowsPipeWriter
destructor that could occur when the reading end was closed before
the write was finished.
Task-number: QTBUG-23378
Task-number: QTBUG-38185
Change-Id: If0ae96dcd756f716ddf6fa38016080095bf3bd4e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The use of QWinOverlappedIoNotifier in QWindowsPipeReader restricts us
in the following ways:
- The handle that gets assigned to QWinOverlappedIoNotifier is forever
tied to an I/O completion port.
- Other notification mechanisms like I/O completion routines of
WriteFileEx do not work with such a handle.
- No other QWinOverlappedIoNotifier can be registered for this handle.
To achieve the ultimate goal of making QWindowsPipeWriter thread-free
(to fix QTBUG-23378 and QTBUG-38185) we remove the usage of
QWinOverlappedIoNotifier from QWindowsPipeReader and use the
ReadFileEx API instead.
This has the additional advantage of removing the need for any thread
synchronization, as the I/O completion routine runs in the thread that
ReadFileEx was called on, leading to simpler and faster code.
Change-Id: I05c983e1f1e49d7dd27e3b77a47f87cae9c3f4c6
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
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>
After canceling the asynchronous read operation, the
notified() slot receives ERROR_OPERATION_ABORTED.
We must not handle this situation as an error.
This amends commit 5ce567c5.
Task-number: QTBUG-48336
Change-Id: Iff948ceb3ad1f805a9de8c188fbc39ed4c76ba82
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The error message mentioned a wrong function name.
Change-Id: Ia2258744fd9268af6b00f54e74d40476ded3b0d2
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
In rare cases the I/O operation was still running after the destructor
was running, which then modified free'd memory and caused a malformed
heap. To prevent this, we ensure that QWindowsPipeReader::stop() cancels
a running I/O operation and sets the readSequenceStarted flag correctly.
Also, we prevent the start of a new read operation after we called stop().
Change-Id: If8a28bdf23a39a0e88c1770a6f66e2b24ea426bb
Task-number: QTBUG-45601
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
There's exactly one caller for this private method, and future code
will be a bit simpler after moving the code to the calling site.
Change-Id: Ibc65f91c770f9f29b317ceddb39a67d52106da33
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
The zero timeout singleshot timer emitReadyReadTimer was used to emit
the readyRead signal via the event loop in case of a synchronous read.
In that particular case, ReadFile would return successfully, and the
notified slot would not be called.
Now, that we use an I/O completion port, the notified slot is always
called, even in the synchronous case. The emitReadyReadTimer is not
needed anymore.
This is also supported by the fact that the timer is immediately
stopped in notified() after it was started in completeAsyncRead().
Change-Id: I93bcde5f067bf89a1d49005a3fddda4c8c8c95fc
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
According to the documentation we should always pass a zeroed
OVERLAPPED object to ReadFile.
Change-Id: I3f822af46a2c38e029e02461f706c4fd91c00c50
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
According to I/O API, QIODevice and its inherited classes should be
able to process a full 64-bit offsets and lengths. This requires
64-bit parameters in operations with internal buffers. Rework
QRingBuffer to avoid implicit truncation of numbers and fix some
64-bit issues in code.
Change-Id: Iadd6fd5fefd2d64e6c084e2feebb4dc2d6df66de
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Outdated header.LGPL removed (use header.LGPL21 instead)
Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination
Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
On Unix systems where the GUI event dispatcher uses a notification
system for socket notifiers that is out of band compared to select(),
it's possible for the QSocketNotifier to activate after the pipe has
been read from. When that happened, the ioctl(2) call with FIONREAD
might return 0 bytes available, which we interpreted to mean EOF.
Instead of doing that, always try to read at least one byte and examine
the returned byte count from read(2). If it returns 0, that's a real
EOF; if it returns -1 EWOULDBLOCK, we simply ignore the situation.
That's the case on OS X: the Cocoa event dispatcher uses CFSocket to get
notifications and those use kevent (and, apparently, an auxiliary
thread) instead of an in-thread select() or poll(). That means the event
loop would activate the QSocketNotifier even though there is nothing to
be read.
Task-number: QTBUG-39488
Change-Id: I1a58b5b1db7a47034fb36a78a005ebff96290efb
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Mårten Nordheim
Lucie Gérard
Sona Kurazyan
Alex Trotsenko
Volker Hilsheimer
Kai Koehne
Allan Sandfeld Jensen
Friedemann Kleint
Simon Hausmann
Joerg Bornemann
Liang Qi
Liang Qi
Joerg Bornemann
Jani Heikkinen
Simon Hausmann
Allan Sandfeld Jensen
Matti Paaso
Thiago Macieira