On Fri, March 30, 2007 5:32 pm, Stewart Stremler wrote: > begin quoting Lan Barnes as of Fri, Mar 30, 2007 at 02:57:26PM -0700: >> >> On Fri, March 30, 2007 2:43 pm, Stewart Stremler wrote: >> >> > There are many alternatives, but each one comes with its own set of >> > tradeoffs (just like threads), so pointing at one or the other and >> > saying "That one is BEST" is really just someone who wants to force >> > their view on to everyone else. >> > >> > I think we need some more languages with built-in threading support, >> > 'cuz the future is looking like multi-core shared-memory systems. >> We're >> > going to be dealing with concurrent programming issues no matter what. >> > We should be exploring that problem space, not avoiding it. >> >> I have assumed that there _are_ problems that must be solved with >> threads; >> else why would they have been added to the Tcl core. > > This sort of reasoning alwasy makes me want to grind my teeth. :) > > That being said... > > NO problem _must_ be solved with threads. They're merely a tool to > produce a simpler design (within bounds) -- and it's all running as > part of one huge sequential program anyway, it's on a Von Neumann > machine. > >> I think it's fair >> for >> an experienced programmer to say, if you find yourself reaching for >> threads (or any other advanced feature), you would do well to return to >> your analyses unless you have one of the bona fide problems that feature >> was designed to cope with. > > Part of my problem is that I've not played with TCL in so long, or > the threading features in TCL at all, I don't know what the warts are. > > But if the threading extensions are any good, then it's a matter of also > asking oneself why _aren't_ you using threads, instead of <other > technique>. > > Everything has a tradeoff. > >> Perhaps I'm less quick to think of this as arrogance (which I'm quick to >> condemn) because I am so accustomed to the measured and courteous tone >> of >> the Tcl lists. There is very little posturing or zealotry there. The >> closest they come to smugness is the occasional "one of the nice things >> about Tcl ..." statements. > > Heh. > > One of the nice things about threads is that it's conceptually simple > to write producer/consumer logic all within the same program. This > thread produces data and shoves it into a data structure, and that > thread sucks data out of the data structure and consumes it. Simple. > > (Coroutines are *almost* as simple, except they still require language > support or ugly hacks (strike 1), and they result in having to grok > both sides of the problem at the same time (strike 2), and they're > difficult to scale up to multiple producers or consumers (strike 3).) >
I'm really tempted to ask you (with no irony) to study up on Tcl threads and do a report to SDTUG. But this might be better -- we could locate a national Tcl'er who is a recognized thread mavin and have a virtual presentation. Interest? -- Lan Barnes SCM Analyst Linux Guy Tcl/Tk Enthusiast Biodiesel Brewer -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
