Tuesday, February 28, 2012

comp.lang.tcl › how can tcl program be written to take advantage fo 8 cpu machine? ipc? message passing? or?

comp.lang.tcl › how can tcl program be written to take advantage fo 8 cpu machine? ipc? message passing? or? 4 posts by 4 authors in comp.lang.tcl Feb 24 (3 days ago) me curious how tclers write programs that are not stuck on 1 cpu GN Post reply Feb 25 (3 days ago) On Feb 25, 1:51 am, gavino wrote: > curious how tclers write programs that are not stuck on 1 cpu libthread, aolserver/naviserver George Petasis Post reply Feb 25 (3 days ago) Στις 25/2/2012 02:51, ο/η gavino έγραψε: > curious how tclers write programs that are not stuck on 1 cpu I use the threads package for this (creates interpreters on different threads), but I wish this kind of usage was easier in Tcl... George Tcl Bliss Post reply Feb 25 (3 days ago) Multi-threaded programming in Tcl is super simple. But, what happens often is that people get confused and scared away by the language used to explain multi-threaded programming, like using mutexes and condition variables. Let me make it clear -- you do not need to know anything about mutexes or condition variables etc. Those can be used for advanced programming, if you ever need them and once you learned the basics. Otherwise, basics are perfectly fine and enough for everyday use. Example: package require Thread; thread::create { #your code goes here} # anything you want to do, the thread exits/closes once your code completes} or set mythread [thread::create]; # this is a long lived thread, you can keep sending your code there, do [thread::release $mythread] to close/exit it. set output [thread::send $mythread {#your code}] or thread::send -async $mythread {#your code} output; vwait output; Although multi-threaded programming is very simple to start with, you only need it in cases where your application reaches 100% CPU usage or you have some code that could block your application from responding for long periods of time, otherwise you just waste memory and reduce performance by needlessly creating and using threads.

No comments: