Comment 7 for bug 1374684

I still think that the way we process incoming MUD data could be suspect in that (void)cTelnet::handle_socket_signal_readyRead() is a SLOT that is coupled to an asynchronous SIGNAL generated by a separate (Qt provided) network thread that manages (QTcpSocket)cTelnet::socket so we have to be careful to make any class members it modifies be used in a re-entrant or is that thread-safe manner? I.e.:

Looks contentious:
(bool)Host::mInsertedMissingLF
(bool)cTelnet::recvdGA
(bool)cTelnet::iac
(bool)cTelnet::iac2
(bool)cTelnet::insb
(std::string)cTelnet::command

Safe-ish probably only because they are not modified frequently:
(bool)cTelnet::mMCCP_version_1
(bool)cTelnet::mMCCP_version_2
(bool)cTelnet::mFORCE_GA_OFF
(bool)cTelnet::mGA_Driver
(bool)cTelnet::mLF_ON_GA
(bool)cTelnet::mNeedDecompression
(bool)TConsole::mRecordReplay

Probably safe:
(bool)cTelnet::mWaitingForResponse
(QTime)cTelnet::timeOffset
(QTime)cTelnet::networkLatencyTime
(double)cTelnet::networkLatency

Note that "command" in void cTelnet::processTelnetCommand(const string &) is a local variable {the passed argument, NOT the class member of the same name which it masks - tut, tut!}