From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <f5f3e6afec94e9687ad272959494da5f@quanstro.net>
From: erik quanstrom <quanstro@quanstro.net>
Date: Wed, 30 Jul 2008 08:50:28 -0400
To: tlaronde@polynum.com, 9fans@9fans.net
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] current state of thread programming
Topicbox-Message-UUID: f51998d6-ead3-11e9-9d60-3106f5b1d025

>
> CSP is (for me) the best answer to problem involving blocking/waiting on
> input. But this is not parallelism.
>

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.

for example, the way ken's fs worked** with the worm is that
n readahead messages read from the rahqueue.  this meant
that they would block on input until there was something
to do.  since there were many cache drives and (i believe)
multiple optical drives, a request loop requesting n
blocks from the rah device could potentially get all the
physical drives going in parallel.

while ken's implementation might not fit the textbook
description of csp, it's pretty close in spirit.

one could argue that isn't *really* parallel because the
requests for the n blocks are made sequentially.
but since drives, operating on the timescale of tens of
milliseconds are competing with a processor working on
a nanosecond timescale.  that's effectively "all at once".

- erik

** the version in extra only starts one rah process and
uses an elevator algorithim on worm addresses.  this
works best on a single-disk system.