Quote Originally Posted by Cruz View Post
I don't understand your aversion against threads.
I'm not against using threads in general, I like threads. I'm against using threads where they provide more problems than they solve or when they are not needed at all. And in general I am against using processEvents(). See my article at Qt Quarterly for more info.

With a seperate thread however the optimized mechanisms of the operating system will take care of driving your process.
This is completely not true, it would be slower than using a single thread And even if it was, try gracefully stopping a thread that is sleeping on read() or write().

In the case of crisp for example the seperate thread can wait in a blocking recvfrom() call and use no resources at all.
This is exactly the same as when using other approaches. The event loops spins anyway, so there is nothing wrong in periodically calling non-blocking select() (which happens under the hood) to see if anything arrived at the socket.

Threads use up resources by the way...

\ New data will be handled exactly when they arrived and not too early or too late as it's usually the case with a timer based approach.
Sure, sky will fall on your head if you see an IRC message 10ms later. What? you are using an LCD screen with refresh rate of 60Hz? Then you will have a bigger delay from your LCD that from using the timer...

Parallel processes also lead to a better utilization of multicore cpus, which are becoming the standard as of now.
This is meaningless in this particular situation as both threads couldn't run at once anyway because at some point you have to synchronize them after reading from the socket because you want to display something on the screen.

People often use threads as an escape from having to write proper event driven code. This is fine as long as the use case is simple. But at some point in time your thread will become more and more complex and you will have more and more problems with synchronizing threads completelly discarding all advantages of using the thread in the first place.

"GUI freezes unless there is incoming data" title of this thread perfectly illustrates one of synchronization issues that has a chance of arising.

By the way, most low latency applications try to avoid using blocking calls in favour of non-blocking ones. In Qt we should always try to avoid making synchronous calls and using threads is not always a good option for that.