| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until Qt 5.5.0, QLocalSocket::waitForReadyRead() immediately returns
when there are still bytesAvailable(). This means our busy loop for
polling new data gets stuck.
To work around this we've been explicitly calling processEvents(),
which however can have undesired side effects: Namely that non-network
events get delivered too, and that 'intermediate' requests are sent
to the server, resulting in the protocol getting out of sync - requests
get replies from intermediate commands, ultimately leading to crashes.
The patch therefore removes the processEvents() call, and instead
works around the QLocalSocket::waitForReadyRead() deficiency by
subclassing.
Task-number: QTIFW-663
Task-number: QTIFW-656
Task-number: QTIFW-659
Change-Id: I4099fa1702cd8dceda954d672c9c3dac0ca7fd66
Reviewed-by: Karsten Heimrich <karsten.heimrich@theqtcompany.com>
|
|
|
|
|
| |
Change-Id: Iaab5bd3821bc4f1d4a826c9fee0c2a8c75d06bba
Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do not assume that the socket always contains enough data. Instead,
prefix every 'packet' with its size, and back off until the full
packet is available.
The actual encoding/decoding is done in Protocol::sendPacket,
Protocol::receivePacket. To be able to use the methods everywhere,
replies are now prefixed by a Protocol::Reply command.
Change-Id: I75a89605b2cc3fe2f2f841d8e3159fc8aea65d77
Reviewed-by: Karsten Heimrich <karsten.heimrich@theqtcompany.com>
|
|
|
|
|
|
| |
Change-Id: I12bfef671ab31ae9fb8c4bb02776517e7f434d27
Task-number: QTIFW-228
Reviewed-by: Karsten Heimrich <karsten.heimrich@theqtcompany.com>
|
|
|
|
|
| |
Change-Id: I8dde6629cfd461104364d5cdc255cb54b58283fa
Reviewed-by: Niels Weber <niels.weber@theqtcompany.com>
|
|
|
|
|
|
|
|
| |
The objectName of a QThread will be picked up and shown by debuggers.
Change-Id: Iabd1006a228a73fff0a9a89bd3d8c1021bab6945
Reviewed-by: Jarek Kobus <jaroslaw.kobus@theqtcompany.com>
Reviewed-by: Niels Weber <niels.weber@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
| |
There's no point in listening to the socket after the
authorization failed. It will then be closed by the client,
anyway.
Change-Id: I26eb2023e08ac3b16ecb894a89ffa0bfeddc62b0
Reviewed-by: Niels Weber <niels.weber@theqtcompany.com>
Reviewed-by: Karsten Heimrich <karsten.heimrich@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
| |
QThreadServerConnection is automatically deleted via deleteLater on exit.
Anyhow, TcpServer::shutdown() also tries to quit() all child threads by
going through the list of children. Making the QThread a child of TcpServer
activates this behavior again.
Change-Id: If1639ae2c9cd74a83b8ff1814aa2131d9016de14
Reviewed-by: Niels Weber <niels.weber@theqtcompany.com>
Reviewed-by: Jarek Kobus <jaroslaw.kobus@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
| |
This is necessary due to a behavior change in QSettings/Qt 5
that now creates ini files with more restrictive permissions
than before.
Task-number: QTIFW-589
Task-number: QTBUG-44086
Change-Id: I296ad4b312a933cbda7dd5c1f644294f83e1850d
Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
| |
The client side (RemoteObject) sends a Destroy message to the socket
when it's done. The server however did continue to listen to the socket
even after the message, letting inactive socket descriptors pile up
until we run out of them.
Change-Id: I659ab8e24a81ab6163a05e2fb8db4dfd47ebd02f
Reviewed-by: Niels Weber <niels.weber@theqtcompany.com>
|
|
|
|
|
| |
Change-Id: Ifeca6563c9b1c82ab754fe87e8cacfae040cc070
Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com>
|
|
|
|
|
|
|
|
|
| |
If we can't connect, the server is most likely not running.
Also send an acknowledgment that we are going to shutdown.
Change-Id: I1a06b0ea5b5bdeb736042ca8b49508b6a4fd90b8
Reviewed-by: Niels Weber <niels.weber@theqtcompany.com>
Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com>
|
|
|
|
|
|
|
|
|
| |
Use signals and slots to tell about the shutdown request.
Instead of passing around the server pointer, give the port
and key as parameter.
Change-Id: I0ad1667aa1caee4ffdee8b6951336f2254974810
Reviewed-by: Niels Weber <niels.weber@theqtcompany.com>
|
|
|
|
|
|
| |
Change-Id: Id2d9ca3043b0d75a7ea93f9ac1f1467059cb1f0b
Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com>
Reviewed-by: Niels Weber <niels.weber@theqtcompany.com>
|
|
|
|
|
| |
Change-Id: Id8301f8691340a41b9d314e8421fb4d245453a5a
Reviewed-by: Niels Weber <niels.weber@digia.com>
|
|
|
|
|
|
|
| |
Change-Id: I61158f956894e209dccf83744b4753774676099d
Reviewed-by: Karsten Heimrich <karsten.heimrich@digia.com>
Reviewed-by: Niels Weber <niels.weber@digia.com>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@digia.com>
|
|
|
|
|
|
|
|
|
| |
Unify if statements for better reading. Implement missing methods.
Adjust {extension, supportsExtension} to tell that our remote does
not support any extensions but our local file engine does probably.
Change-Id: I6c1c392b531e4060cf12bde8b32eb6c6ec8f1037
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Caused by the fact that the settings wrapper did not support
anything different then native format, we had to trick the wrapper
into using its default QSettings object which in turn uses a
QFile (which roundtrips to the admin server) to write the settings
out (behind the scenes). The blocking appeared only on Linux cause
there we try a native call fcntl(handle, F_SETLKW, &fl) to lock the
file during sync, which blocks endless caused of the missing rights.
The fix is to use the settings wrapper also for ini format, as both
are supported (Ini and Native).
Change-Id: I73131c4adf85ba175ba6af1e18acccc29451b14f
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
|
|
Still based on what we had already, though more separated.
Change-Id: I4cce298003a4ffc2ebcec01fea1a07adfbfdf990
Reviewed-by: Tim Jenssen <tim.jenssen@digia.com>
Reviewed-by: Niels Weber <niels.weber@digia.com>
|