Small doubts on signals flux

Stefanoxjx

Hello, I have some doubts about how Qt engine works with signals.
For example, if I work with serial port, Qt emits the readyRead() signal during serial data reception.
My doubt is: if the SLOT (called for example readData ()) that manages data received, for some reason is particularly slow, is possible that a new readyRead () signal is emitted before that readData() is finished?
I hope I explained myself
Thanks.

Stefano

VRonin

Yes, in fact the signal sender has no idea what the slot(s) connected to it do and it "doesn't care"

Flotisable

@Stefanoxjx
as I know, signal/slot mechanism work just like a normal function call, so a signal can only be emitted after a working slot is finished.

Stefanoxjx

ehm!!! Excuse me, I'm not very good with english, but seems that the VRonin response is in contrast to that of Flotisable.
I misunderstood your answers?

Stefano

VRonin

No, they are both correct but there is caveat:

If you connect with Qt::DirectConnection in the same thread then @Flotisable is correct.
If you connect with Qt::QueuedConnection from 2 different threads then my answer holds

mrjj

@Stefanoxjx
Hi
I think both is valid as VRonin say yes,
you can be in your slot and Get a new readyRead while still being in the slot
where as Flotisable says that emit a signal often is like a function call.

so if you do
emit MySignal_1
emit MySignal_2
then its stays in _1 until finished and then emit _2 ( with Qt::DirectConnection )

Anyway, in event driven applications as Qt is, then
no slot should be "particularly slow"
as you might block the whole app or make
it non responsive if your slot lives in the main
thread.

Buckwheat

@Stefanoxjx
If the signal and slot both reside in the same thread, the automatic usage is a direct function call. If they reside in different threads or Queued is specified, the signal gets run through the event queue. They indeed will queue up until they are processed.

I had a case where I wasn't monitoring the event queue (bad setup) and all the work was done and then all of a sudden I got like 1200 signals!

Now, that being said, I have never cared about how Q_EMIT (emit) works. Does it set a flag before the actual meta call so subsequent emits are skipped? I don't think so based on the behavior I mentioned earlier.

Now, @VRonin is correct when he says the system doesn't care. It cares from the prototype POV but like any interface it doesn't care what happens once the data is passed. If your slot reads data, then your read and process ALL the data that is available. Not just a single packet. That will ensure you get all of it.

I would suggest you run your serial port and worker in separate threads so the signals are queued.

Stefanoxjx

OK, I understand.
My doubt is what happens if new signal readyRead() is emitted when readData() is working? (fast or slow it be).
If first call of readData() is working on data buffer, the second call overwrite this buffer.
I should implement one mechanism that return immediately if readData() is already called, but if serial data received are the last bytes, no new readyRead() signal will be emitted and without it readData() don't reads and manage last packet.

I will must think very well to this mechanism for don't have loss data.

kshegunov

@Stefanoxjx said in Small doubts on signals flux:

My doubt is what happens if new signal readyRead() is emitted when readData() is working?

Nothing, the connected slot will wait for the current slot to be executed (assuming concurrency, which is the only way this scenario could happen) and only then it will be called by Qt (when control returns to the event loop).

Stefanoxjx

@kshegunov: Very Good, it is what I was hoping :)
Many thanks at all for help.

Stefano