Home > Multi-threading, programming, Qt > How To Really, Truly Use QThreads; The Full Explanation

How To Really, Truly Use QThreads; The Full Explanation

Threads in an operating system are a very simple thing. Write a function, maybe bundle it with some data and push it onto a newly created thread. Use a mutex or other method to safely communicate with the thread if necessary. Whether it are Win32, POSIX or other threads, they all basically work the same and are quite fool-proof. I’d venture to say that they’re at least a lot easier to use and handle than sockets :)

Those who have discovered the joys of the Qt framework may assume that threads in Qt (QThread) are just like this, but they would be both wrong and right. Wrong because years of wrong documentation from Trolltech/Nokia on QThread has caused countless people to use QThreads in a convoluted and highly inappropriate manner. Right because QThreads are in fact quite easy to use, as long as you ignore the incorrect official Qt documentation on QThread [1] and the myriad of wrongful methods being employed.

The main thing to keep in mind when using a QThread is that it’s not a thread. It’s a wrapper around a thread object. This wrapper provides the signals, slots and methods to easily use the thread object within a Qt project. This should immediately show why the recommended way of using QThreads in the documentation, namely to sub-class it and implement your own run() function, is very wrong. A QThread should be used much like a regular thread instance: prepare an object (QObject) class with all your desired functionality in it. Then create a new QThread instance, push the QObject onto it using moveToThread(QThread*) of the QObject instance and call start() on the QThread instance. That’s all. You set up the proper signal/slot connections to make it quit properly and such, and that’s all.

For a basic example, check this class declaration for the Worker class:

class Worker : public QObject {
    Q_OBJECT

public:
    Worker();
    ~Worker();

public slots:
    void process();

signals:
    void finished();
    void error(QString err);

private:
    // add your variables here
};

We add at least one public slot which will be used to trigger the instance and make it start processing data once the thread has started. Now, let’s see what the implementation for this basic class looks like.

// --- CONSTRUCTOR ---
Worker::Worker() {
    // you could copy data from constructor arguments to internal variables here.
}

// --- DECONSTRUCTOR ---
Worker::~Worker() {
    // free resources
}

// --- PROCESS ---
// Start processing data.
void Worker::process() {
    // allocate resources using new here
    qDebug("Hello World!");
    emit finished();
}

While this Worker class doesn’t do anything special, it nevertheless contains all the required elements. It starts processing when its main function, in this case process(), is called and when it is done it emits the signal finished() which will then be used to trigger the shutdown of the QThread instance it is contained in.

By the way, one extremely important thing to note here is that you should NEVER allocate heap objects (using new) in the constructor of the QObject class as this allocation is then performed on the main thread and not on the new QThread instance, meaning that the newly created object is then owned by the main thread and not the QThread instance. This will make your code fail to work. Instead, allocate such resources in the main function slot such as process() in this case as when that is called the object will be on the new thread instance and thus it will own the resource.

Now, let’s see how to use this new construction by creating a new Worker instance and putting it on a QThread instance:

QThread* thread = new QThread;
Worker* worker = new Worker();
worker->moveToThread(thread);
connect(worker, SIGNAL(error(QString)), this, SLOT(errorString(QString)));
connect(thread, SIGNAL(started()), worker, SLOT(process()));
connect(worker, SIGNAL(finished()), thread, SLOT(quit()));
connect(worker, SIGNAL(finished()), worker, SLOT(deleteLater()));
connect(thread, SIGNAL(finished()), thread, SLOT(deleteLater()));
thread->start();

The connect() series here is the most crucial part. The first connect() line hooks up the error message signal from the worker to an error processing function in the main thread. The second connects the thread’s started() signal to the processing() slot in the worker, causing it to start.

Then the clean-up: when the worker instance emits finished(), as we did in the example, it will signal the thread to quit, i.e. shut down. We then mark the worker instance using the same finished() signal for deletion. Finally, to prevent nasty crashes because the thread hasn’t fully shut down yet when it is deleted, we connect the finished() of the thread (not the worker!) to its own deleteLater() slot. This will cause the thread to be deleted only after it has fully shut down.

I hope this small tutorial is of some use to people out there. It has taken me months to put together this method of doing things involving countless frustrating hours of debugging and Google searches which kept repeating the same wrong mantra of ‘sub-class QThread’. Constructive feedback on this tutorial is much appreciated. Emails to Nokia on the wrong QThreads documentation might be a good idea too as I would love for the myths surrounding QThread to finally be erased from this world :)

Maya

[1] http://doc.trolltech.com/4.7/qthread.html

About these ads
  1. dboddie
    December 6, 2011 at 12:41 AM

    A lot of the reasoning behind the (mis)use of QThread in the Qt documentation is, I believe, left over from the way things were done in Qt 3. I could be wrong. As one of the perpetrators of the “wrong” way of doing things, I wish there could be a better discussion of both approaches in the documentation because it seems to me that each approach has its merits.

    Hopefully, the Qt Project effort will help get updates on subjects like these into the regular documentation, though this ultimately depends on having enough people with commit rights and available time to review and merge them into the mainline Qt tree. If you’re the sort of person who’s motivated to do that then I’d urge you to get involved in the project, or perhaps even to get hired as a writer:

    http://qt.nokia.com/about/careers/technical-writer-in-oslo-norway

    Disclaimer: I worked there until earlier this year.

    • December 6, 2011 at 12:51 AM

      Hi David :)

      Yeah, the origins of such ‘sinful’ approaches to using QThreads are probably lost in history and all we can do now is to try and clean up the resulting mess.

      At this point I do not really have the time to work on the Qt project unless I got hired by them :) Maybe you could forward my CV to them together with the link to this blog and see what they think? ;)

  2. thomaszander
    March 14, 2012 at 9:44 AM

    I have one little worry here, which is a technical detail easilly overlooked.
    I know that deleteLater works by creating an event on the objects event loop, which will delete it when the event queue gets to it. The quit on the thread is implemented in the same way, an event on the queue. And in this case its the same queue.
    So my worry is that the quit is executed before the deleteLater is executed and we have a leak.

    One easy solution might be that you don’t connect the finished() to the threads quit(), instead you connect the workers destroyed() to the threads quit().

    One more thing that might be useful to add here is how to properly delete stuff if the user wants the app to quit before the finished() is emitted. I.e. how to delete the thread properly.
    This typically means that someone in the gui thread calls quit() and then wait() on the thread object.

    Thanks for the blog, excellent summary and overview. Love it :)

    • March 19, 2012 at 3:06 PM

      Hi Thomas,

      The intention is for quit() to be executed before deleteLater(). As a serial queue is used there should be no issue here. As for the rest of your worries, do you mean connecting the finished() signal to deleteLater(), and instead connecting the thread’s terminated() signal upon terminating (as a result of quit()) to deleteLater()? That might work, but I haven’t tried it nor do I know whether it has any benefits.

      This also ties in with calling quit() on the thread directly. There’s no real need to dispose of the thread and wait for its exit unless you’re dealing with a program termination.

      Maya

  3. thomaszander
    March 19, 2012 at 8:56 PM

    Ah, I see my mistake; I’ve not explained which deleteLater() I’m talking about :)
    I think the issue is still there, and my explanation is easy to misread, and I see you commented on something slightly different. Mind if I try again?

    What this starts with is that there are two connects with the SLOT(deleteLater()) in them. Those two connects are handled by two different event queues. The first is on the worker object and due to its moveToThread its handled in the event queue of the ‘thread’ object.
    The second is handled by the main QApplication event queue.

    The worry I’m having is that this is happening;
    * worker emits finished(). This causes 1) a new ‘please-quit’ event to be placed on the threads event queue. 2) a new ‘delete worker’ event to be placed on the threads event queue. 3) a new ‘delete thread’ event to be placed on the main-gui event loop.

    The correct order of execution here is ‘delete worker’, ‘exit thread event-loop’ and last ‘delete thread’.
    In Qt docs I’ve seen often mentioned that the order in which slots are executed is not deterministic. So my numbering of 1,2,3 is not a well-defined order.
    Then there is the fact that this is spread over two threads and the order can be changed due to that too.

    So, in short, I worry that due to event ordering not being enforced we might leak the ‘worker’ object.

    • kakkaroolari
      April 4, 2012 at 11:51 AM

      I think I get thomaszander’s concern, for I share it. Let me try to put it this way.

      In the example code line:
      connect(worker, SIGNAL(finished()), worker, SLOT(deleteLater()));

      This posts an event into the worker thread’s queue to delete the qthread object, when the qthread has finished. But if the thread truly has finished, it doesn’t have an event loop no more, doesn’t consume the deleteLater event, and thus, don’t get deleted.

      My assumption is, that due to a race condition [1] inside the QThreadPrivate::finish, the code works however. It works at least in Qt 4.7, but it might not work in the future versions of QThread. If I understood it correctly, qhtread::finished() signal is emitted on the thread’s context (direct call to qhtreadprivate::finish), so in fact, the qthread is not finished when finished() is emitted. Issue is discussed here:

      http://lists.qt-project.org/pipermail/development/2011-November/000284.html [1]

      • August 28, 2012 at 10:00 PM

        I have looked at my original approach and the one suggested by thomaszander. Without in-depth knowledge it’s hard to impossible to say which approach is more correct. At this point I’m inclined to go with the original approach as described due to it ‘feeling better’.

        I guess someone has to dig through the source of QThread and related some day to answer this question definitely :)

  4. ustulation
    March 25, 2012 at 6:48 AM

    hi,
    i got directed to your blog from a link in an answer on QThreads for the question i posted on stackoverflow.com…ever since i read this article i’v been careful enough to design apps using the guidelines given here making use of moveToThread()…but in a recent case i’v got stuck a little…what if i don’t want a complete GUI app in the sense that there is no main GUI event loop…for instance say i just need the facilities of QFileDialog class which will be modal anyway and will be processed without requiring an event loop…i accept 2 files to process them in a similar fashion and this is time consuming…so i assign 2 files to two separate threads and make use of multicore processor to process them in parallel…the default version on run() in QThread is a mere exec() loop…in such a case how i can i avoid the re-implementation of this run() method? i cannot make connections since i’m not using any event loops…extending this, any app that does not make use of GUI event loops must subclass QThread…So am i missing on a better alternate design pattern here?

    • August 28, 2012 at 10:02 PM

      In that particular case I’d be inclined to use an alternate threading library, such as that of Boost.

  5. mmccullo
    April 20, 2012 at 7:44 PM

    Once problem I’ve encountered with this method is that you cannot access the protected members of QThread such as sleep, usleep, etc. since your thread object is not a subclass of QThread. Is there a workaround for that?

  6. August 15, 2012 at 1:37 AM

    Thanks, I have been hammering my head against a wall trying to get a multithreaded Qt program working correctly. Now it does.

  7. portaloffreedom
    August 22, 2012 at 12:11 AM

    I love you. Really.
    Now I understand why all my slots were executed in the main thread (making my thread useless…). Thank you very much :D

  8. September 28, 2012 at 3:13 AM

    I am forever in your debt, Maya. It is really hard to understand why Qt does not properly document such an important matter. And a tricky one, your optimism notwithstanding.

    If you could enlighten us a little further about thread-local data issues I’d be even more grateful. The Qt code around moveToThread() kind of looks to me like it is meant to transfer heap data to the new thread — but I don’t understand this at all well.

    Then there is the little matter of terminating a thread synchronously and restarting it. Qt docs say QThread::wait() is equivalent to Unix join(). I have been using it where I want to stop and restart some loops that run in threads, and the results so far have been hung GUI thread and/or failure of the restarted loop. Have you an example of how to do this right?

  9. November 16, 2012 at 7:43 AM

    thanx for the insight but how to access static protected static functions like msleep() and sleep() ?

  10. November 22, 2012 at 9:50 AM

    Actually, you can fully use QThread by subclassing it.

    After a few hours of poking around, a came up with this solution: http://engineer-dan.tumblr.com/post/36274332373/subclassing-qthread

    Basically what I did was subclassed QThread, then called moveToThread(this) in the constructor.

    • November 23, 2012 at 7:35 PM

      @engineerdan – Sure, it’s possible to do it that way, but it’s technically speaking the most elegant. The main reason is essentially that you only sub-class when you absolutely have to. Sure, you can sub-class QThread, but with the same ease you can write a worker class instance and push it onto a regular QThread. Ergo it makes sense to only sub-class QThread when you absolutely need some kind of custom thread functionality not present in QThread.

  11. November 22, 2012 at 4:45 PM

    hi Maya
    great article, I’m struggling to get my simple example working though :( (sorry).
    Can I ask some advice, I can’t see where I’m going wrong.
    My main app constructor creates a thread; this thread just contains an infinite loop chucking out a signal every 10th of a second, the slot in also in my main app. This bit is very simple, not the problem (I think).
    So the slot in my main app gets called 10 times a second and contains the code:

    QThread* thrd = new QThread;
    MyWorker* worker = new MyWorker();
    worker->moveToThread(thrd);
    connect(thrd, SIGNAL(started()), worker, SLOT(process()));
    connect(worker, SIGNAL(finished()), thrd, SLOT(quit()));
    connect(worker, SIGNAL(finished()), worker, SLOT(deleteLater()));
    connect(thrd, SIGNAL(finished()), thrd, SLOT(deleteLater()));
    connect(worker, SIGNAL(finished()), thrd, SLOT(deleteLater()));
    thrd->start();

    And the MyWorker class is almost identical to the code you have in your example. When it starts, it calls process() which is just:

    void MyWorker::process()
    {
    emit finished();
    }

    If I run it in debug, after 10 seconds or so I get:

    QEventDispatcherUNIXPrivate(): Unable to create thread pipe
    Too many open files

    It looks like its not deleting the threads :( Any ideas what I might be doing wrong?

    many thanks

  12. January 24, 2013 at 5:49 PM

    This might be related to the concerns some people had further up about the enqueuing of the `deleteLater` events. I’m trying to employ this method in Qt 4.8.3, but the code as presented in this example reproducibly leads to an access violation as soon as the QThread’s event loop gets around to consume the `deleteLater` event.

    It seems that after executing the QThread’s `quit()` function, Qt is about to auto-delete the QThread object, but it is still in some sort of limbo state where the next event, `deleteLater`, is still consumed, to which it doesn’t take well. The same happens when trying to do a `delete thread;` after using `thread->quit(); thread->wait();`, the application will throw an access violation on the delete. I’m not sure if Qt actually garbage-collects these and I’m fine, or whether I’m leaking QThreads by omitting the delete/deleteLater; but if I am, I don’t know how to clean them up since any which way I try crashes my application. Considering it’s the `delete` itself that crashes seems to suggest it’s already been deleted though, right? (Unless the pointer was modified, which it wasn’t).

  13. mefibnstofel
    February 2, 2013 at 10:26 AM

    very informative post. bookmarked.

  14. kakkaroolari
    February 4, 2013 at 8:24 AM

    Daniel Saner :
    This might be related to the concerns some people had further up about the enqueuing of the `deleteLater` events. I’m trying to employ this method in Qt 4.8.3, but the code as presented in this example reproducibly leads to an access violation as soon as the QThread’s event loop gets around to consume the `deleteLater` event.

    After executing qthread::quit, your qthread exits it’s event loop, and should not be sent any (not even deleteLater events).

    What if you, before exiting the qthread context – move you “qobject” back to main thread for deletion, where you still have a running event loop? After “processing”, call this->movetothread(qcoreapplication::instance()->thread()).

    Daniel Saner :
    It seems that after executing the QThread’s `quit()` function, Qt is about to auto-delete the QThread object, but it is still in some sort of limbo state where the next event, `deleteLater`, is still consumed, to which it doesn’t take well. The same happens when trying to do a `delete thread;` after using `thread->quit(); thread->wait();`, the application will throw an access violation on the delete. I’m not sure if Qt actually garbage-collects these and I’m fine, or whether I’m leaking QThreads by omitting the delete/deleteLater; but if I am, I don’t know how to clean them up since any which way I try crashes my application. Considering it’s the `delete` itself that crashes seems to suggest it’s already been deleted though, right? (Unless the pointer was modified, which it wasn’t).

    I don’t think Qt garbage collects anything here – for these objects don’t have a parent. Qt only deletes a qobject’s children. In fact, in order for the qobject::movetothread to work, the object must not have parent (apparently to avoid this garbage collector to delete the object from another thread’s contect).

  15. March 21, 2013 at 5:07 PM

    Thanks Maya, I have spent a good week trying to solve the very same problem using the sub-classing method discussed in my study material. It worked for a while and then suddenly I got dumps and unexpected failures in my code. After changing to the method discussed here and actualy finding that it is documented QT4.8 documentation, it started to work as expected.
    “http://qt-project.org/doc/qt-4.8/qthread.html”

    Using the combination of these two references I got the multithreaded applicaton to work without any issues.

    I do have one question, I have long running threads and it seems like my application is then non responsive. I then tried calling the Qapplication::processEvents() method which I thaught would work simular to Microsofts doEvents() which should make the application responsive but it makes it only run longer.

    The question is, where do have to add Qapplication::processEvents() or what is the most appropriate place to use this method.

  16. jtafurth
    March 26, 2013 at 7:53 PM

    Leaving elegance aside, what is the downside of subclassing Qthread like its done in the official documentation (e.g. Crashes? memory management? horrible shameful shutdowns?) I’m just learning Qt and as far as my experience goes the method works.

    Reading the previous comments I see there are in fact problems with stability, but can you give an insight on why does this happens?

  17. May 7, 2013 at 12:28 PM

    thank you very much Maya! The documentation is indeed lacking… The last connects were very difficult to implement without a proper foreknowledge!

  18. August 6, 2013 at 4:51 PM

    Hi,

    regarding the timing problem of the worker and thread on deleteLater():
    As you explained, it is not guaranteed that the worker will be deleted in time. So my suggestion is to use the destroyed() signal emitted by the worker object:

    connect(worker, SIGNAL(destroyed()), thread, SLOT(quit()));

    Than there shouldn’t be any problem, or?

  19. peterwurmsdobler
    September 6, 2013 at 10:09 AM

    Hello Maya,
    you mention that one should never allocate heap memory in the Object (probably referring to the worker. This may be easily achieve in some applications. My main application needs to allocate quite big resources (many GBs of RAM through NVIDIA mallocHost, mmap’d kernel memory, etc) at the very beginning which are shared across several threads performing work. If I used your approach, all my workers would still have to have references to objects created in the main thread, and of moveToThread of the workers will move themselves to the target thread, but not the objects they contain and work on. How would you go about that?
    Cheers, peter.

  20. September 12, 2013 at 1:40 PM

    Hello Maya,

    I would like to ask few question like Is it possible to assign each thread in separate core in multi core system? If it possible can you please explain how to do this with an example.Is any efficiency will get if we assign the core explicitly oven automatic assigned by OS?

  21. rlranft
    September 23, 2013 at 10:24 PM

    What about the QThreadPool class and its specific use case as described at http://qt-project.org/doc/qt-5.1/qtcore/qthreadpool.html. They’re suggesting subclassing QRunnable; do you think your solution might work with that system?

  22. ianguel
    November 25, 2013 at 1:58 PM

    Quote from above: “By the way, one extremely important thing to note here is that you should NEVER allocate heap objects (using new) in the constructor of the QObject class as this allocation is then performed on the main thread and not on the new QThread instance, meaning that the newly created object is then owned by the main thread and not the QThread instance. This will make your code fail to work. ”

    IMHO the above statement is NOT true if we use a worker QObject and then moveToThread() properly and the heap objects are children of that worker QObject. Maybe the warning only applies to the case where people subclass QThread??? Please correct me if I’m wrong.

  23. November 29, 2013 at 3:21 PM

    Interesting… What if the Worker object is shared between multiple threads running concurrently ?

  24. February 7, 2014 at 9:22 PM

    HI Maya, I’ve been following your other blog for a while (sorry for lurking)… and finally life comes-around… this post has the answers to my python QThread woes. Thanks!

  25. February 12, 2014 at 9:06 PM

    Following on from the posts above.. I’ve spent most of today trying to track down an illusive memory leak in a component i have written to push Pixmap images to a fileshare on its own thread. Turns out it was because of the concerns raised above with deleteLater, using Glowcode to profile my memory usage i found that something was holding a Shared memory reference to the pixmap after everything had been completed. I tracked this down to a QObject i was constructing and pushing onto a worker thread. Granted, it would work 95 out of 100 runs.. But the other 5%of the time the QObject would not be destroyed. I’ve adjusted to using:

    connect(m_pMoveImageToFileShare, SIGNAL(destroyed()), m_pWorkerThread, SLOT(quit()), Qt::QueuedConnection);

    And profiled it again everything is looking a lot better. So a note to anyone using this implementation, it works the vast majority of the time using the ‘finished’ signal from the object to the ‘quit’ slot on the worker thread but it is not bomb proof !

  26. May 8, 2014 at 10:05 AM

    Using QThread is not necessary for a simple case of a simple worker class. The approach in this blog article still has a lot of overkill in it.

    If you modify the Worker class above to the following:

    class Worker : public QObject, public QRunnable{
    Q_OBJECT

    public:
    Worker();
    ~Worker();

    void run();

    signals:
    void finished();
    void error(QString err);

    private:
    // add your variables here
    };

    (Note that the process slot from the blog example gets converted to the run virtual function)

    Then you can use the power and convenience of QThreadPool and skip all the headaches that arise from managing the threads.

    QThreadPool::globalInstance()->start(new Worker);

    • May 11, 2014 at 3:27 PM

      Hi Robert. Of course it might seem overkill in the article, but note that it’s about the correct use of QThread and not whether threads or the right solution to whatever problem one is faced with :) Of course a QThreadPool and QRunnables would be more elegant in many cases, yet again this is not what this article is about. Cases where the use of a QThread is warranted is where one needs a lot of control over the creation, use and disposal of said thread. The Qt documentation also has an article on which type of concurrency to pick depending on the situation.

  27. May 20, 2014 at 7:16 PM

    Eu sou do Brasil. Trabalho como programador , sou iniciante, seu artigo salvou o meu dia. Muito obrigado.

  28. May 28, 2014 at 8:52 AM

    Quote: “you should NEVER allocate heap objects (using new) in the constructor of the QObject class as this allocation is then performed on the main thread and not on the new QThread instance, meaning that the newly created object is then owned by the main thread and not the QThread instance”.

    I have never tried this but since threads are supposed to all share the same heap (they only have a distinct stack), I don’t see why it wouldn’t work. Please check your information.

    Maybe threads have a distinct stack too in Qt but that would be very weird.

  29. May 28, 2014 at 4:24 PM

    “Maybe threads have a distinct stack too in Qt but that would be very weird.” –> sorry, replace stack by heap.

  30. Anonymous
    June 1, 2014 at 5:59 PM

    A great simple example Maya. I linked to it from a blog entry on my page, but I noticed something that could be of concern. As you know, a mutex must be used between threads sharing data. There is also the problem of sharing Qt implicitly shared objects between threads.

    I can see that you pass a QString (implicitly shared) from the worker object to the main GUI thread using a signal and slot. While I haven’t looked into the exact implementation of this signal to slot process, I believe you will get a reference to the same QString at both threads. This means if you modify the QString in one thread while the other is using it, a crash may result. I say may result because it all depends on what code is being executed when the string is modified. The deep copy and reference atomic counting used in implicitly shared objects is not thread safe. It may only crash 1 in 1000 times, but those types of bugs are very hard to find and fix.

    I covered this issue in this blog entry:

    http://www.folding-hyperspace.com/real-time-programming-tips/tip-15-implicit-sharing-and.html

    The example code I provide is somewhat flawed. I haven’t done much work on this because I simply avoid making this mistake and pass only safe non-shared objects on a signal to slot transaction. Perhaps some day I will do some more code testing to prove it is a problem.

  31. September 17, 2014 at 5:34 PM

    Thanks for your post. It is in fact described now in the doc:

    http://qt-project.org/doc/qt-5/qthread.html#details

  32. September 29, 2014 at 2:43 PM

    Hello Maya,

    Building an audio generator, for which I need a QThread – thanks very much for your coherent description of QThread usage.

    Excellent.

    John Russell (.au)

  1. June 24, 2012 at 3:18 PM
  2. January 6, 2013 at 6:18 AM
  3. February 5, 2013 at 9:03 AM
  4. March 26, 2013 at 10:07 AM
  5. April 15, 2013 at 1:02 AM
  6. April 15, 2013 at 7:22 AM
  7. April 17, 2013 at 10:02 AM
  8. May 1, 2013 at 7:06 PM
  9. May 27, 2013 at 11:02 AM
  10. June 6, 2013 at 1:02 PM
  11. August 29, 2013 at 8:36 PM
  12. October 8, 2013 at 6:02 PM
  13. March 27, 2014 at 6:40 AM

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 1,736 other followers

%d bloggers like this: