[Qt-interest] Signal/Slot model is suitable for GUI applications but it isn't for console applications

[Valeriy Portnyagin]

Andre, thanks for detailed response.

Valery.



From:
Andre Somers <andre at familiesomers.nl>
To:
qt-interest at trolltech.com
Date:
23.08.2010 19:52
Subject:
Re: [Qt-interest] Signal/Slot model is suitable for GUI applications but 
it isn't for console applications



Op 23-8-2010 15:21, Valeriy Portnyagin schreef: 
Eirik, 
thanks for the link. 

Let's make the assumption, there is an active intra-thread communication 
with many signals and slots. Is the preferred way to use a native direct 
call of function or to stay in signal/slot model? 

regards, 
Valery. 

I find that using signals and slots is a very nice way to communicate 
between threads, but it is not suitable if you're going to fire loads and 
loads of them. The (de-) marshalling of data and the use of the event loop 
just gets too expensive. That has nothing to do with GUI vs. console 
applications. For sending relatively infrequent updates from one thread to 
another it works just fine though. 

A native call will always be faster than a call through the signal/slot 
mechanism, but you have to consider at what cost. It introduces a strong 
coupling between components that may be better of being loosely coupled. 
It also means that you will have to rely on other thread synchronization 
mechanisms to make sure that you don't run into trouble on that front. 
Just calling a method directly means that you call it from the thread that 
makes the call. If you want to trigger something in another thread, that 
means leaving some kind of message in a queue that the other thread can 
pick up and process in it's own time. All that is possible, but error 
prone. It is basically what Qt is doing for you behind the screens using 
cross-thread signals and slots. There are opportunities for speed 
optimizations, but you'd have to think if it would be worth doing for your 
case, or that there may be ways to just limit the inter-thread 
communication. The whole idea of using threads is that they can do their 
work relatively independent of other pieces of your code. If you find that 
you need a whole of communication between threads, perhaps you should 
rethink your design and see if the division you made is really the best 
one.

André_______________________________________________
Qt-interest mailing list
Qt-interest at trolltech.com
http://lists.trolltech.com/mailman/listinfo/qt-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20100824/1d6e4dcd/attachment.html