[Interest] Which thread implementation is best to trigger external library via timers

[Roland Winklmeier]

Hi list,

for my project I have to use a very old library. This library is written in
C++ and handles high level network and audio stuff. It is not written
asynchronous but you have to call a method

void DoTask();

every now and then. This will handle all queued jobs.
A little bit more background:
In the beginning I did this with a QTimer:
Lets say m_network is a pointer to the libraries Network C++ class.

class NetworkWorker : public QObject
{
    Q_OBJECT
public:
    NetworkWorker::NetworkWorker()
    {
        QTimer *timer = new QTimer(this);
        connect(timer, &QTimer::timeout, m_library, &Library::DoTask());
        timer->start(50);
    }

    QString getIP() const;
    int getPort() const;
    QString getServerName() const;
    QStringList getKnownServers() const;

public slots:

    void setIP(const QString &ip);
    void setPort(int port);

private:
    Network *m_network;
};

I'm aware of the QObject internal timer, I used QTimer for demonstration
purpose.

This works ok, but the tasks are quite time critical so I don't really want
to rely on the application to return control to the event loop. So the idea
was to move NetworkWorker into its own thread.

The question is now, which Thread API is best to use.

1. Subclassing QThread: I've read you should avoid that, so I don't really
consider it
2. Move it to thread: networkWorker->moveToThread(thread);
3. High level API's: QtConcurrent/QRunning

The requirements are:
- Run infinite - stop only when requested
- Needs to run threads event loop
- Able to call slots via queued events
and the most critical part
- direct function calls synchronized via Mutexes from main thread

I've decided to use option 2 but wonder about the following two questions:
- If I have moved NetworkWorker into its own thread, in which thread is
QTimer running and can I be sure even when the main thread is overloaded,
the worker thread still emits and delivers QTimer events?
- There are some methods I still have to call from the main thread, because
I cannot really connect them via queued signal/slots. E.g. getIP() const or
getKnownServers() const. So I still need to call it from a place in the
main thread to get data out of the object:
QString ip = networkWorker->getIP();
Is this still safe to use (of course getIP() is synchronized via a mutex)
or are there any other cleaner solutions?

I hope my explanation is clear. If not, please ask and I try to explain the
issue in more details.
Thanks for your help

Regards Roland

PS: the library sometimes blocks, so this is another reason why I want to
have it in its own thread. But this is just a side note
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20140410/31b25f88/attachment.html>