But again, what is the point of having such a loop? The code above is the same as the previous one, only that you change the condition.
But again, what is the point of having such a loop? The code above is the same as the previous one, only that you change the condition.
I have simply shown all code. Now it is traced there is a connection with the client or not... If connection will be lost before performance of my program (coding of video of a file) that coding will be interrupted, if coding will be normally completed and QProcess will return normal end of the program - the client will receive the answer that all okThanks for the help
At you a unique forum where it is possible to receive the fast and exact answer to a question
![]()
Don't you think listening for the QProcess::finished() signal or checking QProcess::state() is a better way to do it?
So what's the point of monitoring the socket? You don't even need the socket at all... you can use stdin/stdout to transfer all the data you need.
Each connection of the client and performance of process is processed in a separate stream:
Qt Code:
{ return; } } Server::~Server() { } void Server::incomingConnection(int socketDescriptor) { FortuneThread *thread = new FortuneThread(socketDescriptor,this); thread->start(); }To copy to clipboard, switch view to plain text mode
Qt Code:
void FortuneThread::run() { Connection connection; if(!connection.setSocketDescriptor(socketDescriptor)) { emit error(connection.error()); return; } connect(&connection, SIGNAL(disconnected()), this, SLOT(deleteConnection())); exec(); }To copy to clipboard, switch view to plain text mode
I don't see a relation to what the busy loop here... If a connection drops, you'll get an error trying to write to the socket, I don't see what waitForDisconnected() is needed for... And processing application events from within a worker thread (because I assume it is the thread that calls processEvents()) seems suspicious.
But what does waitForDisconnected() do for you? I don't see any point in using it... You have a slot connected to the disconnected() signal, so why wait for the signal in a busy loop?
This is obvious, because timers won't fire and the state won't be able to change.
Maybe processEvents() is wise enough to call the appropriate event queue based on the current thread id and thanks to that your application doesn't crash...
I shall explain. The client has an adjustment - how many simultaneously streams to start. The client considers quantity simultaneously started streams and holds connection until then while process of coding of a file will be completed or there will be a mistake. The server is located on unix, and the client on Windows. Earlier this system on C has been written. But I have decided to try with studying QT to copy this part on QT/C ++
Bookmarks