Mookie
28th January 2013, 22:42
All the Example code in the Threading section are coded in the older style of subclassing QThread. One of the problems I see with this is that every consumer then spawns its own thread.
I have a slow system and have a need for a "best effort" object on a thread. i.e. A consumer that keeps up as best it can with small inputs that come in too fast. If it's busy and 2+ more inputs come in it only processes the latest one on the next iteration. My previous implementation was a loop in the QThread::run() function with a mutex protected input block and a binary semaphore to control the loop. When not in use, the thread merely locks the loop and waits.
As stated above, this has the limitation that every consumer must spawn its own thread. I was hoping to modify this into multiple producers connected to multiple consumers, which could be moved to a generic thread context using moveToThread().
The problem: This architecture provides no concept of "skipping" inputs that are coming too fast. The consumers residing on their own, shared thread rely on the thread's event loop. There's no look-ahead capability to see if a newer signal of that type is waiting in the queue. Has anyone tackled this issue? Ideas?
I have a slow system and have a need for a "best effort" object on a thread. i.e. A consumer that keeps up as best it can with small inputs that come in too fast. If it's busy and 2+ more inputs come in it only processes the latest one on the next iteration. My previous implementation was a loop in the QThread::run() function with a mutex protected input block and a binary semaphore to control the loop. When not in use, the thread merely locks the loop and waits.
As stated above, this has the limitation that every consumer must spawn its own thread. I was hoping to modify this into multiple producers connected to multiple consumers, which could be moved to a generic thread context using moveToThread().
The problem: This architecture provides no concept of "skipping" inputs that are coming too fast. The consumers residing on their own, shared thread rely on the thread's event loop. There's no look-ahead capability to see if a newer signal of that type is waiting in the queue. Has anyone tackled this issue? Ideas?