redirecting qDebug to file, threading question

[jcox23]

Hello,

I installed in my application a custom Message Handler with qInstallMessageHandler
to control the output of qDebug, qWarning and the likes...

For simplicity, let's say that I redirect them into a file...

What's unclear for me now, do I have to take usual precautions regarding threading (locking the file i'm writing on in that case I guess) given that qDebugs are called from the main thread but also from other threads resulting in possibly attempt to write the same file from several places...

Thanks for any answer!

[TMan]

I don't know whether qDebug is thread safe. However, I do know that you can instruct it to write to a file without using qInstallMessageHandler. See docs for QDebug.

[jcox23]

I don't know whether qDebug is thread safe. However, I do know that you can instruct it to write to a file without using qInstallMessageHandler. See docs for QDebug.

this part I got:
here's an excerpt:

#ifndef QT_NO_DEBUG_OUTPUT
QTextStream *out = 0;
QMutex mutex;
 
static void logOutput(QtMsgType type, const char *msg)
{
    QMutexLocker locker(&mutex);
 
    QString debugdate = QDateTime::currentDateTime().toString("yyyy.MM.dd|hh:mm:ss");
    QString message(msg);
 
    // extract the priority of the message
    int priority = message.left(1).toInt();
    if (priority >= 0) message.remove(0, 1);
 
    switch (type)
    {
    case QtDebugMsg:
        debugdate += ":";
        (*out) << debugdate << " " << message << endl;
        break;
    case QtWarningMsg:
        debugdate += ":";
        (*out) << debugdate << " " << msg << endl;
        break;
    case QtCriticalMsg:
        debugdate += ":";
        (*out) << debugdate << " " << msg << endl;
        break;
    case QtFatalMsg:
        debugdate += "[F]";
        (*out) << debugdate << " " << msg << endl;
    }
 
    if (QtFatalMsg == type)
    {
        abort();
    }
}
#endif

#ifndef QT_NO_DEBUG_OUTPUT
QTextStream *out = 0;
QMutex mutex;

static void logOutput(QtMsgType type, const char *msg)
{
    QMutexLocker locker(&mutex);

    QString debugdate = QDateTime::currentDateTime().toString("yyyy.MM.dd|hh:mm:ss");
    QString message(msg);

    // extract the priority of the message
    int priority = message.left(1).toInt();
    if (priority >= 0) message.remove(0, 1);

    switch (type)
    {
    case QtDebugMsg:
        debugdate += ":";
        (*out) << debugdate << " " << message << endl;
        break;
    case QtWarningMsg:
        debugdate += ":";
        (*out) << debugdate << " " << msg << endl;
        break;
    case QtCriticalMsg:
        debugdate += ":";
        (*out) << debugdate << " " << msg << endl;
        break;
    case QtFatalMsg:
        debugdate += "[F]";
        (*out) << debugdate << " " << msg << endl;
    }
    
    if (QtFatalMsg == type)
    {
        abort();
    }
}
#endif

To copy to clipboard, switch view to plain text mode 

but do I need to protect the write to the file?

[stefanadelbert]

I have recently taken the same approach and I wrote code almost entirely identical to yours. I hadn't considered a threading problem though. I'm not explicitly creating any new threads, so I'm not sure that I do need to worry about it.

One thing I was considering was having the logging to file happening in a different thread. The custom MessageHandler could emit a signal that could be handled by a class in another thread. This might solve your (potential) problem as I believe that the signal/slot mechanism is thread safe, but don't quote me on that.

Oh, wait, do quote me on that...

Qt provides thread support in the form of platform-independent threading classes, a thread-safe way of posting events, and signal-slot connections across threads

from http://doc.trolltech.com/4.6/threads.html

This approach also has the advantage of moving expensive file IO into another thread, which might have a positive performance impact.

[tbscope]

To answer the question if qdebug is threadsafe:
QDebug uses a QTextstream. A QTextStream is not threadsafe.
The documentation is not clear about this, but if you look at the source code of qdebug or qtextstream you see there's no mutex locking at all in the code.