> Even with settings that generate results faster it can still > potentially be slow to complete a single cycle.
Indeed, that is why you *need* to find ways to separate the GUI process from the number-crunching. If the number-crunching gets bogged down, you still want the GUI to be able to respond... Note that this cuts both ways; a GUI update (even just changing a few numbers in a box) is very much more expensive than sending a printf to a console, so if you do a lot of GUI activity from within your number-crunching, you will find that the GUI interaction totally hoses your throughput. So, on both counts, you need to separate them as far as is practical. > but regardless of the above, even using fast parameters i > need to allow the user the option of halting it, viewing > results or whatever, then restarting if required. OK, so in my case, I'd have the GUI setting "flags" that the number-cruncher could check for on each iteration, to allow the user to ask it to stop / pause / restart / terminate / whatever... Remember that for threads (unlike processes) all the tasks are running in the same address space, so intercommunication is relatively easy and cheap to do - indeed global vars work fine for this (aesthetic issue notwithstanding) though it might be a good idea to mark them volatile just in case your optimizer gets too carried away at compile time! In extreme cases, if you are using threads and the worker thread fails to stop when asked, you can terminate a recalcitrant thread from the main thread (though how well that works can vary from platform to platform! Also, that can be "untidy" if the worker thread is hanging on to a lot of resources of whatever sort when you zap it...) > Given what i've read today and how it differs from my > traditional idea of event handling, i think this be > accomplished just with the native event structures as > descirbed and a single thread. > > but, given this CPU usage issue (i may block or warn users at > certain settings) then would a second thread be the best option? I favour multiple threads, other may not. The downside of multi-threading this sort of thing is that it can be (usually is) a nightmare to debug if (when) it goes awry. A single thread implementation is perfectly feasible too, of course, though how well that will utilise multiple cores on a modern machine is hard to say. Generally speaking, no current OS does a good job of distributing a single thread C or C++ program over multiple cores, so if you want to utilise all the cores in the users machine, you need to do that yourself. If you have serious number-crunching to do, you need to be looking at scaling the work over multiple cores anyway - possibly adapting the thread-count at runtime to suit the available cores... Though that's off-topic for a GUI discussion, and my be overkill for your use-case. SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
