From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net Date: Wed, 30 Jul 2008 14:58:48 -0400 From: Sape Mullender In-Reply-To: <20080730173156.GA484@polynum.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: Re: [9fans] current state of thread programming Topicbox-Message-UUID: f7445146-ead3-11e9-9d60-3106f5b1d025 >> i don't see how csp is *not* parallel processing. as soon >> as you have more than 1 work process per client, i would call >> that parallel processing. > > It's a kind of parallelism, of course. But since it makes sense, it is > not "parallelism" as the trend is today ;) I don't know what the trend is today. If the trend is defined by what Linux does then I'm not very curious. The point of the Plan 9 thread library was — and still is, as far as I'm concerned — to be a tool that aids in concurrent programming. I'm explicitly not saying parallel programming. I think of parallel programming as a technique for finishing some algorithm faster. I think of concurrent programming as a way of keeping indeterminism under control. A file server serves many customers simultaneously, and must expect requests, disk events, etc. to happen in any order. Managing this is what Plan 9 threaded programs are good at. And our model of using channels for interthread and interprocess communication, while using a thread pool (all in one proc) for managing shared data without needing locks, is the best programming model for these kinds of programs I've ever come across. You can write parallel programs using the thread library but that's not what its primary purpose was and it's probably not going to help you much. Sape