QThread, canceling queue on a connection.

[kghose]

Hi,

I have a thread that emits queued signals to an object. I have a mechanism to stop the thread in mid-processing and restart it with different parameters.

My problem is that I often have an item in the signal queue that arrives at my receiver after stopping the thread.

Is there a way to
a) wait until the queue has flushed (I tried Qt::BlockingQueuedConnection, but that often 'jams' my program)
OR
b) discard the queue at will

Thanks!
-K

[lvi]

How about disconnecting the signal (QObject::disconnect()) and reconnecting it when the thread has restarted? I never used it, but I would assume that disconnecting a signal would discard any queued signals (then again, assumptions are dangerous )

[kghose]

Mmm, I thought about that. I'll try it out and if I live I will report the results of the experiment....

[wysota]

What do these signals do? Do they transmit data? If so then maybe the best way would be simply to have an external queue for data and only inform the processing thread that you have inserted something into the queue? You could probably even use wait conditions for that and ignore signals at all.

[kghose]

Hmm, like a buffer? I've done this for data acquisition before. This sounds nice. So basically I'd have a rolling buffer that sender would write to and reciever would read or not read. Would I trigger the read of the buffer using a signal though? This would put me in the same spot as before - since the two are in differend threads it would be a queued slot...

[wysota]

Hmm, like a buffer?

Yes, a queue to be precise.

Would I trigger the read of the buffer using a signal though?

It depends what the consumer thread does. If you can suspend it then I'd suggest using a wait condition. If you can't suspend it then signals or custom events are the best choice.

This would put me in the same spot as before - since the two are in differend threads it would be a queued slot...

That doesn't matter. This is a "fire and forget" situation. The producer emits a signal and doesn't care if anything caches it. The consumer will catch the signal and look into the queue to see if there is anything to consume, regardless of when that happens (you can clear the queue before you fire the signal). There is no chance of deadlocking here. I'd still suggest using wait conditions if that's possible in your case. If you can't use wait conditions be sure to still protect the queue with a mutex so that you don't read and write to it at the same time.

[kghose]

Hi Lvi,

disconnecting unfortunately does not work for my case - I'm guessing disconnecting does not destroy the queue...but it was an innovative thought!

-K

[kghose]

Heh,

Ok, I found a solution that works for me and I had fun coming up with.

When my data sending thread gets the order to stop it emits one last bit of data (using the same signal and hence the same queue). This data is basically nonsense.

My receiver now checks to see if the data it got was nonsense. If it was, then it just resets its state and whatever comes next is nicely the new data after the data sending thread got restarted.

That was fun to figure out!

-K

[aamer4yu]

How about using sender() in the SLOT and checking if it valid or not.
Sending nonsense data doesnt seem to be a good option. Am not sure, but i feel it

[kghose]

Hi aamer4yu,

How about using sender() in the SLOT and checking if it valid or not.

My sender does not get destroyed, just stopped. Any how, the state of the sender will not tell me how many items there are in the queue and if I should discard them, so that will unfortunately not help.

Sending nonsense data doesnt seem to be a good option. Am not sure, but i feel it

I'm curious, why not?

-K

[wysota]

I really suggest you do it properly using a shared resource. It's easy, safe and nice - all at once.

[kghose]

Hi Wysota,

OK, I will read up about shared resources...

-K