Also consider the option of doing it all in a single thread. You don't need a separate thread just to receive data over network.
Also consider the option of doing it all in a single thread. You don't need a separate thread just to receive data over network.
And how can I accomplish that? The data transfer is triggered by a button. So first thing that happens is that a signal (clicked()) is sent into a slot. Coming from Java Swing I was raised to return an event handler as quickly as possible, otherwise I will keep the gui thread busy and the gui itself will freeze. So this is why I decided to start a thread from there and to return the slot as quickly as possible. So unless Qt itself takes care of splitting out a thread to handle the slot, so that the gui is not blocked by my sluggish program, I don't see how I can solve it without a thread.
Longer explanation is here:
http://doc.trolltech.com/qq/qq27-responsive-guis.html
In short, network transfer is asynchronous - you schedule some request and then return from the function and Qt will notify you using a signal that the data is ready. You can then process it (read it to a buffer or process immediately) and return from the function. When more data arrives, you will be notified again. In the meantime the application can do other things (like refresh the user interface or make coffee).
Cruz (16th January 2009)
I see where you are coming from. Well, actually it's not really a network connection, it's a more complicated custom USB communication with a robot. I simplified that detail in my question. It means that I can't take advantage of the solid network com solutions that Qt offers. And with that being gone, I personally think that the worker thread is the most elegant solution from all the alternatives proposed on that page.
That doesn't change anything. It's a remote data source, that's all that counts.
Sure you can. You can read from USB in an asynchronous way, you can even use QExtSerialPort probably and there are always timers. Threads are really not required here.It means that I can't take advantage of the solid network com solutions that Qt offers.
Well... Java itself is said to be elegant and that probably ends its advantages over other languages. Doing everything in threads is a nice separation of code but it is often crude when it comes to communication with other components and it adds some overhead to the application. Using signals and slots and event-driven flow gives you the same separation without the down sides. Sure, it might look hard at first but once you grasp it, it becomes very natural.And with that being gone, I personally think that the worker thread is the most elegant solution from all the alternatives proposed on that page.
Bookmarks