On 7/10/07, skaller <[EMAIL PROTECTED]> wrote: > On Tue, 2007-07-10 at 12:12 -0400, Sandro Magi wrote: > > > Convinced of what? The concurrency safety? The security claims? E > > covers quite a bit of ground. > > The basic problem is finding the right primitives to build > parallel system on top of: the key property is probably > composability. > > Felix uses a CSP like model with threads and channels. > I'm "not convinced" you need anything more, or that this > is not in fact the best possible axiom set. > > A key advantage of those constructions is that they > can be implemented to work with blinding speed.
As long as you can continue useful computation while blocking, and you can do so safely, then you have a good concurrency model. I'm not sure I see wow your approach is more efficient or safer than futures+event loops (doesn't seem less efficient either). Allocate a lightweight thread+channel or a future+continuation, I think they're more or less equivalent efficiency-wise, and even conceptually. > The model also corresponds the THE most well known > and heavily used parallel computing paradigm: chips > and circuits. That model in turn has some very heavy > duty category theoretic bases. > > However, as always, the primitives aren't what you > need for everyday programming. Still it can be used. > > In the SDL demos I use this. It provides vastly superior > composition and modularity properties -- you make > some chips, and wire then together to make others. > > The big problem here is that the circuits are static: > you have a global set of wires connecting the chips. > Dynamic extensions needs ways to make the wire names > anonymous .. such as the simple example of unix filters. So what you want is functional reactive programming (FRP), which provides such dynamic circuit switching. You should definitely look into it if you haven't already. What you describe, basic primitive values and combinators to wire circuits, is essentially a dataflow graph as built using FRP signals/events + combinators. However, there are concurrency dangers in executing this graph naively. See FrTime [1] for details. These are the exact same concurrency problems that event loops in E solve. I agree that there are many safe concurrency models; event loops have a fairly simple implementation/conceptual model for imperative programmers. I also find FRP quite compelling, but it is more difficult for your average programmer who isn't familiar with combinators and HOF. > So .. I'm not convinced of the need for a 'vat' or what it really does etc. A 'vat' is pretty much the 'process' abstraction, which I think you'd agree is fairly important and well-founded. The vat is the unit of concurrency, failure, persistence and resource control. E also enforces the property that each 'process' has a single event loop by which all computation is driven, and this+persistence turns a process into an E vat. Sandro [1] http://www.cs.brown.edu/~sk/Publications/Papers/Published/ck-frtime/ ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Felix-language mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/felix-language
