Shorter waits to break the polling
loop when the test finishes and we
need to terminate.
Change-Id: I79d9d89675d0a37f25a03b265b3ae636a90e57d5
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
This merges multiple implementations of
assertCorrectThread and simplifies its
usage.
Change-Id: I7be5dea62c6046fb0412d7f885fcbcc4b66e3fd9
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
The normal path is now streamlined and error handling
is at the end. We also now always set the disposition
to closed and fire onDisconnect() when disconnected
or hit an error.
Change-Id: I984ad71601b92b8042dc7984e7339f0804c8083b
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
We use our own status codes, which
are type-safe and use streaming
operators to serialize and log.
Change-Id: I0eba7b16694866b5a79476a7ef4b1b78f7f9c176
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
This is needed to correct overload
resolution of these operators.
Change-Id: I02c0859674efe112102a8d3833bfb0a30b1a6574
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
For some reason we only checked for the closed
socket case as failure and returned 0 in that case,
for error cases, we returned 1. Likely the API
had been modified in the early days, but this
return code was left lopsided.
This meant that even when the handshake failed, we
still called readIncomingData or writeOutgoindData,
depending on whether we wanted to read or write,
causing a rare race-condition.
When a client (HTTP request) connects to a server,
it needs to send the request, right after the
SSL handshake. SSL_do_handshake could need data
from the socket to complete the handshake. In such
a case it returns WANT_READ. Unfortunately,
because we always called SSL_read, the missing data
could have arrived between the SSL_do_handshake call
and the SSL_read call (a rather short duration, to
be sure, but an open window all the same).
SSL_read would of course read said data from the
socket and, since it still needs to finish the
handshake, will buffer it. It then returns the very
same error that the SSL_do_handshake returned:
WANT_READ. Of course we will oblige by polling with
POLLIN, which will time out (there is no more data
to come, and the server is waiting for *our* request
and has nothing to send us).
The only way this deadlock could break if
SSL_do_handshake was called (which will consume
the buffered data, return 1 to indicate handshake
has completed). Since we wouldn't call it unless
and until we get POLLIN, per WANT_READ, which won't
happen in this case. And since SSL_read doesn't call
SSL_do_handshake either, the request times out and
that's the end of it.
The fix is to not call SSL_read when the handshake
isn't complete and needs more data, which we do now.
Fortunately, we have very few SSL clients, outside
of unit-tests. Most notably the WOPI client. But
even then it's not a heavily used connection and
might not even be SSL-enabled (for LAN servers).
Change-Id: I04fd3dae151904194f3d7579dbf8c671b2580ffb
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
A rare edge-case happens when we have a socket
that is closed (and we get POLLHUP or POLLERR)
but upon reading the socket we get EAGAIN.
This was observed when simulating EAGAIN,
and it is possible that this is quite impossible
in practice (since we read only when we get
POLLIN), but at least for the unit-tests
we need to handle this case, so we don't
get random failures.
Change-Id: I77af1726066507af5d5ada68fe11b479a4e579e5
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
We don't have to read the wakeup pipe
under a lock. So we no longer do.
Change-Id: I6bd724b9748add3022b4f9aa2268094b9818f3e5
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
We now always handle socket polls without skipping
when the number of sockets change. We verify the
socket FD of each socket before handlingPoll to
catch any violations of the preconditions.
This should avoid missing any events and also
handles timeouts better (which are checked
in handlePoll). It also protects against
unexpected modifications of the sockets, with
proper logging and assertion.
Change-Id: I5659eb57231a490e6c813e7a0222443b534713c6
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
Reading larger blocks should avoid having
the pipe back up when we accidentally
attempt more wakes than actual ones.
Change-Id: I7766230f60dbf069668ee7919f766e9093df7017
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
There is no use-case for calling the
thread function of the SocketPoll
from outside.
Change-Id: Id8e87369494817aaab749d03d1cd4cd3724c2da1
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
This replaces the hard-coded status-code
numbers with named compile-time constants.
Change-Id: Ibe678fb2c533b29efd696e4430f5377523eeb298
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
I had added some extra debugging output to the !MOBILEAPP branch to
log values of timeoutMaxMicroS and timeoutMaxMS and was wondering why
I saw things like:
timeoutMaxMicroS=5000000 timeoutMaxMS=5009
and
timeoutMaxMicroS=0 timeoutMaxMS=9
Signed-off-by: Tor Lillqvist <tml@collabora.com>
Change-Id: Iac8599ce5b00ef90d62eabc29c5d92858e276bb6
Apparently it woke up the world unnecessarily.
Change-Id: Iad65215da898b017860e7d7b803771f657a3e1ab
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
When shutting down, SocketPoll threads asynchronously
stop and exit. This fundamental race means the warning
is useless and noisy.
Change-Id: I3ca9044c9a68689abb7e8f692fffd10509eadab6
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
sendCloseFrame does check for the socket to be
there, but it logs an error if it isn't because
it assumes we expect to have a socket.
Since we are shutting down, this code could
be triggered on destruction when we no
longer have the socket.
Change-Id: I622a24394632159aa71c1c21c33c0f8a2d5c6250
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
It seems we were always pinging immediately on a
newly created WebSocket, even before upgrading to
WS, which logged a warning. That was because we
create the WebSocketHandler instance with a
timed-out lastPingSentTime.
Here we correctly set lastPingSentTime such that
it times out *after* InitialPingDelayMicroS has
elapsed. This gives it time to upgrade the
socket to WS and avoid the warning.
Change-Id: I6004348b9b4bd29f614d9e010fb7649da2bca338
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
We no longer emit a fatal (FTL) log when
forced-exiting successfully.
Also, improved are some other logs to
better reflect the severity of the issue.
Change-Id: I22e79f685825f7ecd47cec76c9be9683deff2d55
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
Messages are high-frequency events and logging
them at debug level is too noisy. Increase the
level to trace.
Debug level should produce legible entries that
outline the main activities, rather than log
each message. That is best done at trace level.
Change-Id: I722ab8b58e0adcab6ecb2f8c571966af0d952051
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
The UnitBase reference must be a member of the class.
Change-Id: Ia0b10ccb7f0f3419470f014a23c7a48d3b390239
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
In WebSocketHandler, we often already have
locked the weak_ptr, so we can pass that
shared_ptr around.
Change-Id: Iaedceff0acbfd747bdf89771f9309ff6f6642b53
Signed-off-by: Ashod Nakashian <ashod.nakashian@collabora.co.uk>
