The commit a841b28 changed the condition for removing job from processing.
New flag MultiplexerJobStatus::continue_servicing become used
instead of checking pointer for NULL.
However for cases when TCPSocket::newJob() returns nullptr
the behaviour changed: earlier the job was removed, but after change
it is called again, since MultiplexerJobStatus equal to {true, nullptr}
means "run this job again".
This leads to problem with eating CPU and RAM on linux
https://github.com/debauchee/barrier/issues/470
There is similar windows problem, but not sure it is related.
https://github.com/debauchee/barrier/issues/552
Since it looks that the goal of a841b28 was only clarifying
object ownership and not changing job deletion behaviour,
this commit tries to get original behaviour and fix the bugs above
by returning {false, nullptr} instead of {true, nullptr}
when TCPSocket::newJob() returns nullptr.
Its possible poll() will return that a socket is both readable and
writable. When this happens TCPSocket::serviceConnected() is
overwriting the result from doWrite() with the result from doRead()
This can cause a situation where doWrite() tried to notify that we
should stop polling if the socket is writable, but the doRead() result
causes that to be ignored. This results in a tight loop and 100% cpu
usage in SocketMultiplexer::serviceThread() as the poll() call
instantly returns that the socket is writable, but no one cares that
it is. The issue eventually corrects itself with enough mouse
movement/clicks.
where it belongs. previously SecureListenSocket would delete the client
socket but TCPListenSocket would not. PacketStreamFilter would then
attempt to delete the socket regardless of what type it was. this would
cause an access violation when SecureListenSocket attempted to delete
the socket again.
fixes#3
