Looking for real time data (Timer vs Thread)

[kumararajas]

Hello all,

I want to refresh the data displayed on UI. Since Qt process the events, I do not want to get blocked by keep looking for the incoming data.

I did implement a timer and on time out I go and check if there is any incoming data.
I just felt that, this is not an efficient implementation.

I can also spawn a thread, which can continuously look for the data and emit the signal to my Qt.

Is there any other recommendation?

If no other ways, then please suggest thread vs timer.

Thanks!

[jsulm]

@kumararajas How do you get the data? Is there any kind of notification when new data arrives?

[kumararajas]

@jsulm That's the problem, I do not get any notification. I need to look for the arrival of data.

[SGaist]

Hi,

Where's that data coming from ?

[kumararajas]

Data is coming from other processes.

My Qt application sends the request to get data from other process.

Other process responds with the data. But the response can come any time. This all happens through IPC.

So I cannot make my Qt process to wait for the data arrival, which will block the event loop.

I am looking for a better solution.

Thanks!

[A Former User]

@kumararajas said in Looking for real time data (Timer vs Thread):

This all happens through IPC.

Which operating system, which IPC mechanism?

[kumararajas]

@Wieland It's Linux and I see your point, if IPC mechanism can signal the application about incoming data, Is that your thought process?

I guess no, Linux does not signal us back. And also, above linux IPC, I have written a wrapper for bringing in the portability.

May be any RTOS, can do this job, but my platform is Linux, not RT Linux.

And also, if we can see this problem at a broader picture than solving at low level, will be nicer. Because, tomorrow someone can have same problem, example on MAC Operation System.

If IPC can't provide a feature of 'Callback' then application shall implement the logic of retreiving the data smartly.

I am still in dilemma if Qt has any better way or else, thread or timer, which can be a better option or are there any other smart ways.

Thanks!

[SGaist]

IPC is a generic term. What's the exact technique used ?

Local socket ?
Shared memory ?
Etc.

[kumararajas]

Message Queue.

[A Former User]

@kumararajas said in Looking for real time data (Timer vs Thread):

I can also spawn a thread

This. By default, msgrcv() blocks indefinitely until either a message of the desired type is available or an error occured, man msgrcv(2). To implement a timeout / to properly terminate the thread, you install a signal handler (see Calling Qt Functions From Unix Signal Handlers) and send yourself a SIGALRM, man alarm(3). msgrcv() will then immediately return EINTR.

Edit: BTW, if you can, maybe better use D-Bus or sockets.

[kumararajas]

@Wieland Thanks for the thoughts!

I understand what you saying. But it is a bit tricky situation for me, in my specific case.

I am using mq_send and mq_receive for sending and receiving the message queues. There are wrappers written long years back to send and receive IPC messages (queues). And they are not tied up to Qt to send signals. Nor, these wrappers does not hook to the call back or send 'unix' signals.

So I am just living with the system that was built years together which does not help me to get signal when the message arrives.

I was thinking if I can do anything around application to hack/hook and get the signals. Like any of custom signal handlers can continue to monitor the data through my own function ( IPC receive message wrapper ).

I know that, I am not asking for a neat solution (which you have provided), but any decent solution which can solve the problem.