A Simple Threading Example
A topic that I've not mentioned in any of my blog posts is threading, not because I have anything against it, simply because a simple use-case hadn't come up. Today I was coding something easy to describe, where using threads was a good solution, so let's take a look at it.
The problem I needed to solve was to calculate cryptographic hashes of files that could be very large - for example 4 gigabyte DVD isos. As with any graphical application it is very important to ensure that the GUI remains responsive while this work is done. Since the problem involves very little communication between the part of the application calculating the hash, and the rest of the code a worker thread is an ideal solution.
The code that actually does the work is very simple, it uses the handy QCryptographicHash class to do the work (stored in the variable hasher):
HasherThread::HasherThread(QObject *parent) : QThread(parent) { hasher = new QCryptographicHash( QCryptographicHash::Sha1 ); } void HasherThread::run() { QFile f( filename ); if ( !f.open(QIODevice::ReadOnly) ) { emit error( QString("Unable to open file %1").arg(filename) ); return; } hasher->reset(); char buffer[16*1024]; qint64 count; do { count = f.read( buffer, sizeof(buffer) ); if ( count == -1 ) { emit error( QString("Read error") ); break; } hasher->addData( buffer, count ); } while( !f.atEnd() ); emit completed( hasher->result().toHex() ); }
The code opens the file to be hashed, then reads through it in 16K chunks which it passes to the hasher. If this code were executed in the application's gui thread then this would cause the interface to freeze until the hash was ready, but the code lives in a class that inherits QThread.
One important feature to note about the code above is that the communication with the rest of the application is via signals (the error and completed signals to be precise). This is very important as it means that when we use the class, we can simply use it like this:
hasherThread = new HasherThread( this ); connect( hasherThread, SIGNAL(error(const QString &)), ui->resultEdit, SLOT(setText(const QString &)) ); connect( hasherThread, SIGNAL(completed(const QString &)), ui->resultEdit, SLOT(setText(const QString &)) );
The special thing in the code above, is that we didn't have to do anything special - Qt just solved our inter-thread communication issues for us. What I mean, it that if our code had simply tried to output the result by calling ui->resultEdit->setText() directly then we would be attempting to access the GUI from outside the GUI thread which would most likely cause our application to crash. Instead, since we're using the default type of connections 'AutoConnection', what this means is that Qt will spot if the thread in which a signal is emitted is different from the one in which it is received and handle the necessary synchronisation for us - nice!