QtCraft API C++ classes QML types Handbook

QcSessionThread Class

The thread a session's tick core runs on (decision E-560), named "session tick". More...

Header: #include <clientcore/tick/QcSessionThread.h>

Public Functions

QcSessionThread(const QcSessionThread &)
~QcSessionThread()
void run(std::function<void ()> job)
void start()
QThread *thread() const
QcSessionThread &operator=(const QcSessionThread &)

Detailed Description

A network join starts it before it connects, so the TLS socket is made, used and closed in this one thread (decision E-872: Qt's OpenSSL backend keeps the socket's TLS state in an object that never changes threads). Owned by the thread that made it; run() is the only way in from there.

Member Function Documentation

[delete] QcSessionThread::QcSessionThread(const QcSessionThread &)

Copy-constructs an instance of QcSessionThread. This function is deleted.

[noexcept] QcSessionThread::~QcSessionThread()

Gives the sockets lingering in the thread at most 1 s to send their last frames (QcTcpTransport::finishLingering()), then ends the thread and waits for it.

void QcSessionThread::run(std::function<void ()> job)

Runs job in the thread after what was queued there before and waits until it returned. Hands over through a std::mutex, so ThreadSanitizer sees that the job's effects come before what the caller does next (Qt's event queue inside the uninstrumented QtCore it does not see). Never from the thread itself; only after start().

void QcSessionThread::start()

Starts the thread. What was set up before (objects moved to thread(), pointers they read there) needs no further hand-over: starting a thread orders it before the thread's work.

QThread *QcSessionThread::thread() const

Returns the thread.

[delete] QcSessionThread &QcSessionThread::operator=(const QcSessionThread &)

Copy-assigns other to this QcSessionThread instance. This function is deleted.