Ann: Stackless Limbo Dancing Works Fine!

[Fernando Pereira]

On 5/27/02 10:00 PM, in article uf5p9rtfun1d66 at corp.supernews.com, "Andrew
Henshaw" <andrew.henshaw at mail.com> wrote:

> If you do go with the single-process-pair channels, I wouldn't worry about
> trying to enforce that convention, as the Occam compiler does.  Unless it
> was easy to restrict, I'd let the primitive implementation be open to
> abuse.  If a more "correct" implementation is needed, subclass it and
> impose the process constraints at a higher level.  I have an "Occam"
> library module (poorly done) that I've written to work with the Python
> standard threads, and the primitive channels work fine for me, without the
> checking.
If you assume 1-to-1 channels but don't check, wouldn't the effect of
breaking the assumption be that errant tasks could hijack channels and
create zombie tasks? In particular, if t1 writes to c1, until something
reads from c1, t1 blocks, which would be represented by storing t1 in c1's
write-wait slot (a single wait slot for reading and writing is also
possible, since we are assuming that write-read matches immediately move
both writing and reading task to the run queue). Now if t2 accidentally
writes to c1, since you don't check for this situation, the wait slot in c1
would be overwritten by t2. But t1 is still suspended, and now it won't ever
wake up! (similar problem with hijacking the reading side). It would not
cost much to test that there was a writer suspended on c1, and throw an
appropriate exception.

-- F