2014-04-10 10:16 GMT+02:00 Mandeep Sandhu <mandeepsandhu....@gmail.com>:
> > 1. Subclassing QThread: I've read you should avoid that, so I don't > really > > consider it > > Not really. Search the archives, where we've had this discussion > numerous times before! :) The conclusion was that there's no 1 right > or wrong way. It has to be taken on a case-by-case basis. > > > 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? > > I think, QTimer will run in whatever thread it's parent is in and > since NetworkWorker will parentless (for moveTothread() to work > properly) it should run in the worker thread. Though you might want to > start it _after_ moving NetworkWorker to the new thread so that timer > events are delivered to it's event loop. > > > - 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? > > It should be ok, if the resource access is serialized with a mutex. > > I couldn't gather from your explanation as to why you need an event > loop in the thread? There are no signals being emitted by the worker. > If "getIP()" is ok being a direct call, and if there's only the main > thread trying to set values, then I guess even "setIP()" could be a > direct call (serialzed access via mutex ofcourse). > > Just my 2 cents. > > HTH, > -mandeep > Hi Mandeep, the real worker class is a lot more complex. It has about 10 signals and 15 slots. It is a higher level networking library which implements a specific protocol. When a packet is received, it is parsed and a signal emitted. The other way round is similar, a slot will create a packet and send it to the server. This is part of an event driven application approach and is completely transparent. A example looks like: Timer to ping the server on regular basis: - QTimer::timeout connected to slot sendPing(); - when the pong is received, the signal void pongReceived is emitted, this can be evaluated by the application. But as said, there are methods in the worker, I need return data immediately, e.g. getKnownServers, isConnected etc. Your answer helped me already a lot. Thank you very much. So I'll go for this approach. Roland
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
