Description
From old Google Code repo:
Think about whether python-csp "syntax" is optimal. The thoughts below are from an ancient email thread, never implemented:
One is that I would like to see Process
es, Par
s, Seq
s and Alt
s (and Barrier
s / Bucket
s / ... if possible) as combinators in python-csp that are all "first-class" and can all take one another as arguments to their constructors. It would be nice and elegant to avoid special cases here. So we could say things like:
myProc() // [myAlt(), mySeq(), myPar(), myChannel()]
and all of those would run in parallel.
Clunky syntax, the issue now is that we're close to this in python-csp, by having only two sorts of base classes in the library: processes and guards. Guard
s are for synchronising on and processes
are for computation, but a guard cannot be "run" like a process can and a process does not implement read
/ write
/ select
like a guard does. Python works by duck typing, so the real difference between Guard
and Process
types is that the latter implements a start
method which starts a process running, and Guard
s can "read" and "write". Barriers break this model entirely because we have used Channels()
as being the default sort of guard, which I'm now beginning to question.
A very simple way to unify guards and processes would be for an Alt
, when it "runs" to have an infinite loop which repeatedly calls Alt.select()
(and variants of that for priority selection, etc). Equally, we could have ReadChannel()
and WriteChannel()
classes which read()
and write()
indefinitely, and so on. I'm not sure how the converse would work by allowing processes to be synchronised on, but the answer could be to make Barrier
s the base class for guards, and
have Channel
s extend the Barrier
class and change round all the method names to suit.
This is relatively simple to implement, but I'm not entirely sold on it as a way forward. Firstly, when synchronisation primitives get more complicated I'm not sure if the model will break down. Bucket
s are something we'll want to have for our own work on pervasive computing and no doubt there will be other useful primitives too. Secondly, I haven't (yet) written a nice CSP model of all of these ideas, but i think it's worth doing, not so much to check deadlocks as the scheme is quite simple, but really to get a better idea of the style of programs which might result.