Ann: Stackless Limbo Dancing Works Fine!

[Andrew Henshaw]

Christian Tismer wrote:

> Fernando Pereira wrote:
>> On 5/25/02 1:29 AM, in article ueu89e5dafsmb3 at corp.supernews.com, "Andrew
>> Henshaw" <andrew.henshaw at mail.com> wrote:
>> 
>>>The Occam compiler will
>>>prevent that behavior; but, when programming with C (with Transputer
>>>libraries for parallel processing), this technique is used, occasionally.
>> 
>> Occam != CSP
> 
> Fernando, this is not at you, but at the whole thread:
> 
> Please let me add -- with every respect --
> 
> Stackless != Occam and Stackless != CSP.
> 
> I really appreciate any input on this, and I do my very
> best to find Python's place between these worlds.
> But please make these liveable for me.
> 
> I'd really appreciate if we can keep unrelated
> stuff, may it be real discussion or just hairsplitting,
> out of this thread. Just change the subject to what it is.
> 
> I am looking for help on an issue that's not my home match.
> Discordance on these issues might make me want to leave them.
> Please, all, your task is to make me do the right thing(TM),
> which is a real challenge. Internals have for sure their own
> auditory. Please continue with advice, which was great so far.
> 
> kind regards - chris
> 

Christian,

Sorry about the hijacking of this thread.  I only mentioned that Occam and 
CSP implement channels as connections between single pairs of processes as 
I thought that approach might let you simplify your design (by eliminating 
your proclet queues, perhaps).  I was also trying to show that with this 
primitive approach, you can still construct the more complex behavior that 
you were indicating.  I certainly don't think that you need to emulate 
Occam for some compatibility reason.  If this concept doesn't help you with 
your design, by all means, go with multi-source, multi-destination 
channels.  I'd still love to have them!

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.

Thanks for your efforts!

Andy