 E - secure,distributed, pure OOP and p2p scripting language
started 12/31/2001; 6:02:32 AM - last post 1/4/2002; 10:48:38 PM
|
|
Ehud Lamm - E - secure,distributed, pure OOP and p2p scripting language 
12/31/2001; 6:02:32 AM (reads: 4372, responses: 6)
|
|
| E - secure,distributed, pure OOP and p2p scripting language |
|
(vai HtP)
Marc Stiegler's draft tutorial book on E language programming, The E Language in a Walnut seems very readable, and informative. He writes:
- E is the best language introduced to date for developing distributed systems. As one quick example of its power, the E Promise Architecture ensures that deadlock cannot occur.
- E is the only sensible language introduced to date for secure distributed systems. All communication in E is strongly encrypted, transparently to the programmer. Capability-based security makes writing and auditing the security elements possible to an extent heretofore unachievable....
- E is the first language ever introduced that is able to cope with multi-party partial-trust mobile code. "Mobile code" is just about anything executable on your computer that you get from somewhere else.
For those familar with Ada: In Ada task communication and synchronization are interwined. The rendezvous between tasks synchronizes the two tasks, and then normal parameter passing happens. E uses the the opposite approach: the eventually operator sends a request, but doesn't require synchronization.
This makes sense since, in E, we are thinking about distributed prograaming, and not about tasks running on the same computer. (Indeed, the Ada Distributed System Annex itself isn't based on the rendezvous mechanism).
Even if you are not really interested in E, you may find the discussion of language underpinnings for capabilities interesting (you have to scroll down a bit; no direct link). It talks about language features that make security problematic.
E is currently implemented on top of the JVM.
Posted to OOP by Ehud Lamm on 12/31/01; 6:24:43 AM
|
|
|
|
Frank Atanassow - Re: E - secure,distributed, pure OOP and p2p scripting language
1/3/2002; 1:02:23 PM (reads: 2844, responses: 1)
|
|
deadlock cannot occur
I looked at this, and it looks like the "eventually" operator just passes a closure to some other process. When the closure is called, it needs to imperatively update some variable in order to communicate with the original process. Is there more to it?
I don't see how an untyped language can make static claims about preventing deadlock, unless it's merely sequential. I would be more comfortable if they would show some completeness result with respect to a translation to some well-known concurrency language, like pi-calculus or CCS.
Perhaps someone more knowledgeable about E can explain this.
|
|
Ehud Lamm - Re: E - secure,distributed, pure OOP and p2p scripting language
1/3/2002; 1:11:41 PM (reads: 2987, responses: 0)
|
|
|
I don't know enough about E to say anything definitive, but I found this claim problematic. The eventually operator doesn't involve waiting, so can't result in deadlock. Fine, but what happens when you need the result of the method? Why can't a deadlock occur then?
Maybe someone found a more complete discussion of this?
|
|
Frank Atanassow - Re: E - secure,distributed, pure OOP and p2p scripting language
1/4/2002; 9:37:20 AM (reads: 2831, responses: 1)
|
|
|
There is a when-catch construct which gets executed on the local machine after a response to the eventually operation arrives. So, the code which directly "needs" the response only gets executed when it arrives. (This is why I said it looks like a closure: the when-catch is the body of the closure.)
The problem is: how does the when-catch block share its result with the rest of the program? As far as I can see, it must update some imperative variable which is in both scopes, the scope of the eventually and the scope of the when-catch. So it seems like this just reduces to shared-memory parallelism. And the eventually thread still can deadlock by blocking on or polling the variable which gets updated by the when-catch block.
|
|
Ehud Lamm - Re: E - secure,distributed, pure OOP and p2p scripting language
1/4/2002; 12:11:07 PM (reads: 2974, responses: 0)
|
|
|
Exactly. The when-catch block doesn't seem to solve any real problem, in the sense that if a pice of code needs the result in order to continue its execution it (obviously) must wait for the result.
|
|
Darius Bacon - Re: E - secure,distributed, pure OOP and p2p scripting language
1/4/2002; 10:36:20 PM (reads: 3597, responses: 0)
|
|
|
|
Darius Bacon - Re: E - secure,distributed, pure OOP and p2p scripting language
1/4/2002; 10:48:38 PM (reads: 3227, responses: 0)
|
|
|
About the `eventually' operator ``passing a closure to some other process'' and then updating some shared variable to communicate with the original process -- that's not quite right, although `eventually' does form a closure. The closure will be called in the same vat (E's version of a process) but in a later vat turn, which executes atomically. Any variables involved are not shared between vats; they can't be, because the only official way to communicate between vats is through asynchronous messages. (It's also possible for a program to be granted access to a filesystem and then you would have the usual race conditions -- E could have been pure and modeled filesystem operations as eventual sends too, but I guess they compromised for familiarity.)
This doesn't change the fact that E has a logical equivalent of deadlock (even if supposedly not a practical equivalent). I just didn't want to let that misunderstanding go by.
|
|
|
|