Ann: Stackless Limbo Dancing Works Fine!

[Andrew Henshaw]

Fernando Pereira wrote:

> 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).

I believe that you are absolutely correct.

> It would
> not cost much to test that there was a writer suspended on c1, and throw
> an appropriate exception.
> 
> -- F

If it wouldn't cost much to test, then I'd say that is the way to go.

Andy