Multy-core CPUs

Hi,

Slicing up the data objects and shipping them in one deep copied parcel
from one Smalltalk image to another isn't a general solution. It may be
a solution for some problems that can be simplified but it will NOT work
for the majority of problems. In fact I'd find a "deep copy and split up
the data objects only solution" quite useless for most of the parallel
problems that I'm working on solving.

In the general large scale case that I gave as an example (in an earlier
email) the one million data objects could be retrieved or accessed by
any of the 10,000 processes used in the example. While shipping them all
in a deep copied parcel in one message is possible it's not always the
wisest move. If the compute notes are going off line than it may be
required but otherwise the general case of shipping references and a
core set of objects is a better approach. In the example it was the
"search patterns" that were sliced up across the processes. By slicing
up the data objects across the processes the example given won't even
work! This of course alters the example in a dramatic way. Now this
might be successful for that group of problems, such as rendering where
the pieces are independent. A key characteristic of the general problems
is that the data objects can and must be accessible from ANY of the
forked off processes with ANY of them being able to alter the objects at
any point in time with those changes being propagated back to the
central node (assuming there is just one central node) when a commit
occurs and then updating the other forked off processes that have an
interest in seeing updates to objects in mid transaction. Some of these
changes will of course nullify the work of some of these processes
requiring them to abort and possibly start over with the newest changes.
Too many interacting changes between the processes will of course cause
too many aborts and retry (assuming that's the chosen mechanism for
dealing with overlapping changes that are mutually exclusive resulting
in inconsistency to the data objects).

So while it's useful for some problems to simplify the problem to the
split up the data and spread it across N process nodes it's not viable
for a much larger set of problems that it is viable for. Solving for 90%
of the cases will thus require much more than what is being proposed by
the simplify concurrency at the loss of capability proponents.

It should be noted that there isn't one solution for the general case.
What are needed are solutions that cover various chunks of the solution
space and a way of selecting the correct solution mechanisms either
manually or automatically (preferred if viable). Then the "deep copy and
split up the data objects only solution" may do it's part as a piece in
a wider matrix of solutions. To dispense with the tools we need to solve
the general problems is folly IMHV (In My Humble View).

An excellent book for learning the ins and outs of concurrency control -
and most importantly the common mistakes - is the free PDF book, "The
Little Book of Semaphores",  by Allen B. Downey and his students:
http://www.greenteapress.com/semaphores/downey05semaphores.pdf. Enjoy
the full power of parallel programming.

As an aside, one of the reasons that we don't have better object filing
out across all the Smalltalk versions is that the original Smalltalk
only provided the extremes of shallow and deep copying of objects. To
work the middle ground where only portions of an object graph were
copied took a lot of work since you had to write it from scratch each
time. What is needed is a general purpose method of doing this important
job for the widest range of use cases.

All the best,

Peter William Lount

Hello Peter,



PWL> I'm using ThunderBird for emails. I use nested quoting and
PWL> everythinglooks good to me. Obviously your email program isn't

I get two kinds of mails from you, textmode, properly indented and
html which I don't see indented.

I just verified on Gmane that your html is also properly indented, so
I'll have to fiddle with the settings of my mailer.

Sorry for bothering you!


PWL> working the sameway. Which program do you use? What is "the bat"?

My email program is "The Bat" www.ritlabs.com. In the past when I made
this decision, Thunderbird didn't have a thread view.




Cheers

Herbert                            mailto:[hidden email]

Hi Herbert,

It's all good. I'd not heard of The Rat before. Sounds like an
interesting reader. Thunderbird packages up both text and html so others
can choose which way to view the posting.

What are your thoughts on the whole concurrency issues being debated?

Cheers,

Peter



Herbert König wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

gruntfuttuck wrote:
> How is squeak going to handle multy-core CPUs, if at all? If we see cores of
> 100 plus in the future and squeak stay as it is, I would imagine other
> languages such as erlang, will look more attractive.

Anyone followed links that Andreas gave?

        http://www.erights.org

???

There is a dissertation that addresses two fundamental problems:
- - it introduces synchronization mechanisms that are meant to escape
  from the situation where you
  - either have interference
  - or non-deterministic deadlock
  (Erlang does not solve these problems.
   The recent book about Erlang does not even mention the word "deadlock")
- - *security*

It is a point-of-view-changing reading.

It is true that it is far less mature for production quality, but taking ideas from something as
primitive as Erlang ... well, good luck.
- --
Matej Kosik
ICQ: 300133844
skype: matej_kosik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHIFcoL+CaXfJI/hgRAux5AKCy100+3z/AS3+/GhTevVW9uS8VDgCgw2e5
5yJj4MDA59uTyTXQX+3M6bQ=
=gtQ3
-----END PGP SIGNATURE-----

"Matej Kosik" <[hidden email]> wrote:
>
> gruntfuttuck wrote:
> > How is squeak going to handle multy-core CPUs, if at all? If we see
cores of ideas from something as
> primitive as Erlang ... well, good luck.

Why exactly is Erlang primitive? What do you mean? Do you mean that it can't
solve real-world problems?

It's proven itself in at the very least its original target market, that of
the highly concurrent environment found in things like telephony switches.
It certainly seems applicable in other highly concurrent environments. We're
not talking about some new thought experiment - this is a language that was
released in its open source form in 1998, and whose initial development
started in 1986. There are case studies of _successful_ large systems
(Ericsson's AXD301, in particular).

frank

Because they prioritized the conceptual model "workarrounding machines" to
provide an acceptable overall user experience. Machines are to be used by
persons. They are only important to materialize consequences of it's use.
They should be meant to improve quality of life of persons and/or the
environment. With a personal value like that, very deeply affecting all your
thought, it's obvious that systems has to be made priorizing intellectual
ergonomy and heuristic principles.

The case you David are citing about Self, a system in which designers
managed to prioritize the conceptual model over the boolean, it's a rare and
precious coherent sample of what I'm saying.

If we program computers for some time *we know* there allways be ways to
optimize how things are done. So, if making a system, like this Smalltalk of
"One Process Per Instance", results that it has to consume some more
computer resources than others, I say "I don't care" because it's machines
work. Hardware it's becoming less worst and RAM and cores cheaper and
cheaper very fast. I don't feel empathy for machines, I use them to extract
value for me and other persons. So if that is the case lets do clever things
to mitigate the conceptual-boolean impedance mismatch instead of endlessly
discusing about machinery madness that pollute our ideas. As David say, Self
people has showed us mitigation in hard cases is possible by it's example.
Smalltalk it's a splendid example also.

But this idea is about making the conceptual model to refine rising one
step. To step forward in a direction that will bring us unprecedent
scalability without compromising the simplicity we have today in Smalltalk.
I'm not saying it's the only path but I think it deserves more exploration
because seems to me that it's a path of success in a world of increasing
need of persons modeling it's complexity using machines. And in this path, I
think Smalltalk has a chance to be vanguardist. Again.

All the best,

Sebastian
PS1: Some people claimed I'm being too philosophic, maybe I am because it's
necessary to gestate a solid fundation to build things over it. But it's ok
nothing wrong with that claim, lets embrace pragmatism also. Use the list,
express yourself about this. Your experience or opinions may be important
for others or to continue cogitation.
PS2: I also read Peter posts and I think he's is very good arguing and he
seems to have a very valuable experience. Peter what do you think about this
One Process Per Instance Smalltalk?

Hi Frank,

Frank Shearar wrote:
In what ways is Erlang better than E?
In what ways E cannot be extended to be as good as Erlang?

E  supports objet-oriented programming.
Erlang is not object-oriented.

Non-deterministic deadlocks cannot occur in E.
Non-deterministic deadlocks can occur in E.

E can be used for building open systems (where various parties can cooperate despite the fact that
they do not trust each other ultimately). Erlang does not provide such mechanisms.

E can be used for building systems internally composed from multiple untrusted components without
security risk because E provides mechanisms that enable programmers to follow with principle of the
least authority.
Principle of the least authority cannot be followed in Erlang. Any part of the Erlang system has the
authority to destroy the whole system and perform irreversible damage.

I do not say that E is perfect. I only believe that it is more valuable than Erlang (with respect to
future) and should not be demoted just because it is not popular. Of course, the more people use a
particular language, the bigger chance that it will ripe (to its full potential/but no further).
- --
Matej Kosik
ICQ: 300133844
skype: matej_kosik

Hello Peter,


PWL> It's all good. I'd not heard of The Rat before. Sounds like an
                                     ^^^^^^^ nice Typo :-)))
                                     
PWL> What are your thoughts on the whole concurrency issues being debated?

my practical knowledge in this comes from hardware interrupts (mainly
digital signal processing) with hard realtime demands. (If you loose
an audio sample every one will hear it. The live performing musician
will hear a 5ms processing delay, even worse if it's not constant)

This is a very special case. I decided against memory locking to avoid
complexity. I use a kind of semaphore for synching but simpler.

The number of processes (5) is manually manageable but barely. Hard
realtime constraints are out of the scope of Win/Mac/Linux OS.

Otherwise I clearly lean towards Jason's proposal of

self breakupStructureWith: 10000 ... and no fine grained locking.

But that's because the problem areas I'm concerned with all fall into
categories which benefit from this proposal and won't die of excessive
copying. But that's no valid argument in the discussion :-) But I
tucked away Jason's mail in case I start parallelizing apps.

So I follow the discussion very interested and close and I hope to
never have to solve the kind of problems you use as examples :-).

If I have to, First thing I'll read your suggested book on semaphores.
Maybe earlier for fun.

BTW I'm an engineer not a cs person.


Cheers

Herbert                            mailto:[hidden email]

> Quoting Sebastian Sastre <[hidden email]>:
...
what do you think about this One Process Per Instance Smalltalk?
>
>
I'll answer an important aspect that just came to my mind: persistence.

Question: we won a persistence solution at the same price of making a one
process per instance Smalltalk?

Well lets see... "one crisis at the time"
 
I decided to interpret that all database madness is because the industry was
trying to think is normal to share writes. And I decided to interpret that
the shared write is not normal but a trade off that was made in the industry
to win some usage at the price of "buying the concurrency problem" for us
all.

With One Process Per Instance we have put aside the shared-write so closed
the door to it's whole big space of problems.

I speculate about how an image of this Smalltalk would raise in a host with
the million objects of the intensely dense graph that Peter bring as
example.

Of course one million processes can't be reasonably run in a laptop of any
of us today so we are forced to think differently from how a current image
starts up today. So perhaps we can manage that million by taking 4K light
processes at the time in a let's say 4 core processor CPU with 4G of RAM.

But how this will work? Differently from an image of current smalltalk that
reifies all instances in RAM at startup, this will reify objects on demand
(lazily) in a swarm of instances of N thousand at the time. N will be
trivially and directly depending on the hardware resources.

And what happen when a demand of reaching an instance occurs? The VM assigns
a process and a little portion of RAM for that instance that will be stick
to it as long as it's reified and not garbage collected. Please note that I
said that only that process it's allowed to write. That only happens if not
previously reified. Once an instance is reified, so it has it's process
assigned and it's portion of RAM, it can receive the message.

And what happen when you save an image like that? The VM has assigned that
portion of RAM to that process but the system just gives a different support
(medium) for that piece of RAM. It trivially maps RAM to disk. No impedance
mismatch. Just the instance format plus a way to locate it when needed
again.

So? Well.. that way every piece of RAM dedicated to an instance has an
homologous dedicated piece of disk.

And? And that piece of disk can only be written by the process of it's own
instance provinding guarantee that it never ever ever never ever will be
inconsistent.

Oh.. so we won a persistence solution at the same price of making a one
process per instance Smalltalk? I have serious doubts about fault tolerance
to power faliures and such but putting that in a second plane I'm starting
to think that yes we do because a commit will be a mere flush of that disk
or medium and you never need to rollback anything just write or do not do
it.

Intriguing...dont you think?

Sebastian Sastre

"Matej Kosik" <[hidden email]> wrote:
"deadlock")
> >> - - *security*
> >>
> >> It is a point-of-view-changing reading.
> >>
> >> It is true that it is far less mature for production quality, but
taking
> > ideas from something as
> >> primitive as Erlang ... well, good luck.
> >
> > Why exactly is Erlang primitive? What do you mean? Do you mean that it
can't
> > solve real-world problems?
> >
> > It's proven itself in at the very least its original target market, that
of
> > the highly concurrent environment found in things like telephony
switches.
> > It certainly seems applicable in other highly concurrent environments.
We're
> > not talking about some new thought experiment - this is a language that
was
> > released in its open source form in 1998, and whose initial development
> > started in 1986. There are case studies of _successful_ large systems
> > (Ericsson's AXD301, in particular).
>
> In what ways is Erlang better than E?
> In what ways E cannot be extended to be as good as Erlang?

Well, Erlang is "better than" E because I know of at least one large system
written in Erlang, while I know of none in E. That's not much, I know :)

I certainly don't mean to imply that E has nothing to teach Smalltalk - I
think there are LOTS of languages out there that can teach us LOTS of
things.

> E  supports objet-oriented programming.
> Erlang is not object-oriented.

Well, _that's_ certainly not evidence of being primitive! Haskell's not
object oriented either, nor is Lisp (without CLOS).

> Non-deterministic deadlocks cannot occur in E.
> Non-deterministic deadlocks can occur in E.

What is the difference between E's promise architecure, and Erlang's
combination of ! and receive? (! sends an asynchronous message to a process,
and receive checks the mailbox of a process for messages in a blocking
fashion, and can time out.) I mean, is one more powerful than the other?
(From my cursor reading of E in a Walnut, I think they're equivalent.)

> E can be used for building open systems (where various parties can
cooperate despite the fact that
> they do not trust each other ultimately). Erlang does not provide such
mechanisms.

Sure; Erlang focuses on _concurrency_ issues, not security ones.

> E can be used for building systems internally composed from multiple
untrusted components without
> security risk because E provides mechanisms that enable programmers to
follow with principle of the
> least authority.
> Principle of the least authority cannot be followed in Erlang. Any part of
the Erlang system has the
> authority to destroy the whole system and perform irreversible damage.

Yes, much like, say, Smalltalk. That doesn't make Smalltalk primitive. On
the other hand, perhaps one could implement an E-on-Erlang.

Then again, while it's usual for distributed Erlang applications to run in a
trusted environment, there's nothing stopping one from writing applications
that use sockets to communicate, in which case the Erlang applications's as
secure or insecure as you make it. (Yes, I know, E addresses exactly this
issue.)

> I do not say that E is perfect. I only believe that it is more valuable
than Erlang (with respect to
> future) and should not be demoted just because it is not popular. Of
course, the more people use a
> particular language, the bigger chance that it will ripe (to its full
potential/but no further).

So you feel that E is superior to Erlang because, while both support
equivalent ways of writing distributed programs, E focuses on security
issues right from the get-go?

Anyway, I just object to (pejoratively) labelling a language as "primitive"
when it has delivered on what it set out to do.

frank

On 10/24/07, Sebastian Sastre <[hidden email]> wrote:
>
> So I'm stating here that in a smalltalk image of the future *every object
> should have a process*. Every instance. All of them.

That is an interesting idea.  That would open a door to a new way of
Garbage collection, because it can then be tied to the exit of a
process.

> Said that I return to the problem you stated about the need of copy copy
> copy, saying that this premise changes things and you don't need to copy
> anymore because a VM like that, no matter who or when, an instVar of an
> object is to be modified it will provide you of guarantee that the write
> will be made by the process that corresponds to that instance.

Yes, in such a system, you don't need to copy because all that gets
passed around are references to processes.

On 10/24/07, Igor Stasenko <[hidden email]> wrote:
> Sebastian, you can envision that any unique object in VM is a unique
> process. No changes required to VM. Your concept having zero worth for
> me, because VM already supports that each objects have own
> encapsulated state, and you can change object's state only by  sending
> messages to it.
> So, we already might say, that all objects are living and can be
> represented as a processes which triggered by sending message(s) to
> them.

But not exactly.  The difference is the threads of execution.  Today
the thread of execution belongs to processes, not objects.  So if two
processes call a method on the same object at the same time... race
condition.  If the thread of execution belonged to the objects
themselves this couldn't happen, the different requests would have to
wait in line.

On 10/25/07, Matej Kosik <[hidden email]> wrote:
>
> Anyone followed links that Andreas gave?

Yes, some of it.  Looks like it's based on the futures model.

>   (Erlang does not solve these problems.

No one *solves* these problems, the actor model Erlang uses is just a
good way of dealing with most of the cases.

On 10/23/07, Sebastian Sastre <[hidden email]> wrote:
>
> But that will introduce a singularity in the paradigm. I'm afraid that
> accept that is too much. Can you find a way of archieve the goal of your
> proposal without devastating the "all is an object" premise?

Where is it broken?

> And accepting singularities like that is how a language gets it's syntax
> polluted and developers has to compensate that uncompletism by having to
> remember (and model) in it's brains N more rules. The worst of course is not
> the syntax but damaging the paradigm. That's is accepting the policy of
> unloading of work the machines to load humans. As I see things humans are
> not here for that and machines are not here for that. Dear Jason, I'm in the
> "opposite corner of the ring" for that policy.

Huh?  I'm not talking about adding new syntax, I'm talking about using
the (afaik) unused ! binary operator for sending messages.

> Mmmm no. I mean that every message send should have a process ala Erlang. Of
> course this will only optimize in the other cores the messages sends that
> are parallelizable (discern on which is a question that deserves
> cogitation). Maybe is just a modest improvement to take advantage of
> multicore but it never has any intention to disrupt the paradigm.

Your ideas are interesting, but I'm a quite incremental builder.  Add
one little thing after the other and see how far we get.

On 10/25/07, Peter William Lount <[hidden email]> wrote:
> Hi,
>
> Slicing up the data objects and shipping them in one deep copied parcel
> from one Smalltalk image to another isn't a general solution. It may be
> a solution for some problems that can be simplified but it will NOT work
> for the majority of problems. In fact I'd find a "deep copy and split up
> the data objects only solution" quite useless for most of the parallel
> problems that I'm working on solving.

Ok, you just made a jump there from "majority of problems" to "most of
the problems that *I'm* working on".  It works just fine for the
problems I'm interested in at the moment, and obviously for most of
the problems businesses, etc. are using Erlang for.

So what are these "majority of problems" you're talking about and who
is solving them now?

> In the general large scale case that I gave as an example (in an earlier
> email) the one million data objects could be retrieved or accessed by
> any of the 10,000 processes used in the example. While shipping them all
> in a deep copied parcel in one message is possible it's not always the
> wisest move.

And why would you do that?  No paradigm can remove the responsibility
to think from the programmer.  As I've said I don't know how many
times, the point of this is simply to move this to design where it
belongs instead of implementation where it is now.

Sharing memory is breaking encapsulation.


You lost me again.  You seem to come up with a problem *and the way
you want it solved* and then complain that a message passing paradigm
can't solve it.  What does that prove?

> Solving for 90%
> of the cases will thus require much more than what is being proposed by
> the simplify concurrency at the loss of capability proponents.

Your 90% is different then mine then.  In fact, I can't think of any
concurrency problems I wish to resolve that this *wont* handle.

> What are needed are solutions that cover various chunks of the solution
> space and a way of selecting the correct solution mechanisms either
> manually or automatically (preferred if viable). Then the "deep copy and
> split up the data objects only solution" may do it's part as a piece in
> a wider matrix of solutions. To dispense with the tools we need to solve
> the general problems is folly IMHV (In My Humble View).

We already have.  Or is Squeak/most Smalltalks folly?  There are
certain classes of memory management that don't work well with a GC,
but would with manual memory management.  Is it a mistake to deny it's
use at the language level?

> An excellent book for learning the ins and outs of concurrency control -
> and most importantly the common mistakes - is the free PDF book, "The
> Little Book of Semaphores",  by Allen B. Downey and his students:
> http://www.greenteapress.com/semaphores/downey05semaphores.pdf. Enjoy
> the full power of parallel programming.

For me that's just old-think.  Solutions to incredibly complex
problems we never would have had if we simply avoided violating
encapsulation.

Hi,
It would be helpful if people pointed to specific web pages or papers
rather than simply pointing to ENTIRE web sites. Even better would be to
quote the material (unless that's inappropriate for copyright reasons)
in their posting. It does take a while to digest this stuff and there
are lots of links and papers flying around. Thanks very much.

Is there a particularly cogent link on erights.org that we should look at?

Thanks again,

Peter

Jason Johnson wrote:

On 10/24/07, Sebastian Sastre [hidden email] wrote:
  

So I'm stating here that in a smalltalk image of the future *every object
should have a process*. Every instance. All of them.
    

That is an interesting idea.  That would open a door to a new way of
Garbage collection, because it can then be tied to the exit of a
process.

  

Said that I return to the problem you stated about the need of copy copy
copy, saying that this premise changes things and you don't need to copy
anymore because a VM like that, no matter who or when, an instVar of an
object is to be modified it will provide you of guarantee that the write
will be made by the process that corresponds to that instance.
    

Yes, in such a system, you don't need to copy because all that gets
passed around are references to processes.


  

hi,

What? That just won't work. Think of the memory overhead.

Tying an object instance to a particular process makes no sense. If you did that you'd likely end up with just as many dead locks and other concurrency problems since you'd now have message sends to the object being queued up on the processes input queue. Since processes could only process on message at a time deadlocks can occur - plus all kinds of nasty problems resulting from the order of messages in the queue. (There is a similar nasty problem with the GUI event processing in VisualAge Smalltalk that leads to very difficult to diagnose and comprehend concurrency problems). It's a rats maze that's best to avoid.

Besides, in some cases an object with multiple threads could respond to many messages - literally - at the same time given multiple cores. Why slow down the system by putting all the messages into a single queue when you don't have to!?

Tying an object's life time to the lifetime of a process doesn't make sense since there could be references to the object all over the place. If the process quits the object should still be alive IF there are still references to it.

You'd need to pass around more than references to processes. For if a process has more than one object you'd not get the resolution you'd need. No, passing object references around is way better.

Even if you considered an object as having it's own "logical" process you'd get into the queuing problems hinted at above.

Besides objects in Smalltalk are really fine grained. The notion that each object would have it's own thread would require so much thread switching that no current processor could handle that. It would also be a huge waste of resources.

Again, one solution does not fit all problems - if it did programming would be easier.

All the best,

Peter

Jason Johnson wrote:

On 10/25/07, Matej Kosik [hidden email] wrote:
  

Anyone followed links that Andreas gave?
    

Yes, some of it.  Looks like it's based on the futures model.

  

  (Erlang does not solve these problems.
    

No one *solves* these problems, the actor model Erlang uses is just a
good way of dealing with most of the cases.


  

Hi,

"...most of the cases"? Hardly! It barely scratches the surface.

The "process-based model of concurrency" - as used in Erlang - is but one approach in a wide range of techniques that provide solutions for concurrency. It doesn't solve every problem in concurrency - I don't even think that they claim that for it. If they do please show us where.

Further the example of the one million object graph being processed by 10,000 compute nodes processing the problem is that you don't know in advance how to slice up the data. If you can know in advance how to slice up the data then you've simplified and possibly optimized the problem solving. However, that's the problem, slicing up real world data object sets that are highly interconnected with each other and processing them in parallel. That's an example of a more general case. There are other examples that won't compute with the slice em and dice em approach using the process-based model of concurrency.

Peter

Frank Shearar wrote:
I am sorry. This wasn't the proper word.

Certainly, I believe that there are things that cannot be modelled in the pure functional language
(whose constructs can be without exceptions mapped to the lambda-calculus). This is not only the
case of input/output. This is also the case of modelling stateful systems that interact with their
environment over time (not only at the beginning and at the end). So pretending that functional
programming can cover all the important aspects of systems we need to model is unfaithful. Those
impurities are useful.

>
>> Non-deterministic deadlocks cannot occur in E.
>> Non-deterministic deadlocks can occur in E.
>
> What is the difference between E's promise architecure, and Erlang's
> combination of ! and receive? (! sends an asynchronous message to a process,
> and receive checks the mailbox of a process for messages in a blocking
> fashion, and can time out.) I mean, is one more powerful than the other?
> (From my cursor reading of E in a Walnut, I think they're equivalent.)

Well, their semantics is different. I am used to objects and I want to describe systems as mutualy
interacting objects. My bank acount is an object, it has some state and some methods. I find it natural.

Erlang's processes are somewhat similar to objects, they create illusion of polymorphism (this is
useful) and encapsulation. However, internally, Erlang processes are expressed procedurally. In E,
behavior of processes (vats) is expressed as mutually interacting set of objects. So objects are
polymorphic, not only the whole process.

E and Erlang are similar that internal behavior of a process is sequential and the whole process
acts as a "monitor" (although in E ensures also partial ordering of messages. This is also useful.)

If the statement "(non-deterministic) deadlocks cannot occur in E" is correct (and this is
fantastic) then E's communication mechanisms are less expressive than Erlang's. In Erlang you can
write systems with non-deterministic deadlock. In E you cannot. So less expressive language need not
to be a disadvantage.

E ensures partial ordering of messages passed around (also transitively). Erlang does not. This has
implications.

Erlang does not provide you directly with promise pipelining (it had to be added) whereas it is
directly available in E.

I agree. Neither Erlang nor Smalltalk were designed with security in mind. Funny thing about
security is, that if you do not get it right in the beginning, you cannot "add it later".

> That doesn't make Smalltalk primitive. On
> the other hand, perhaps one could implement an E-on-Erlang.

It is possible, but it would be E, not Erlang.
(although it might be more efficient than E-on-Java)

>
> Then again, while it's usual for distributed Erlang applications to run in a
> trusted environment

Suppose WatchMorph in Squeak. It can delete you home directory. Watch morph is simple so you can
read the code and check it. In case of non-trivial system it would not be realistic.

In E, you can put the untrusted code into a powerbox---thus, giving it as much authority as it needs
and you are willing to grant it. Then, despite the fact that it is an untrusted piece of code, you
can use it and it can be useful. Not using these techniques is a missed chance. Security cannot be
"added later".

Erlang cannot be used for writing software this way.

> there's nothing stopping one from writing applications
> that use sockets to communicate, in which case the Erlang applications's as
> secure or insecure as you make it. (Yes, I know, E addresses exactly this
> issue.)

This would mean emulating E.

Again. Sorry.

>
> frank
>
>


- --
Matej Kosik
ICQ: 300133844
skype: matej_kosik

Well ok, that's a pretty good break down of the problems of such a
thing.  Though it wasn't my idea and I'm not invested in it.

Of course the one thing I have to disagree with in your message is the
comment about an object responding to multiple messages.  I wouldn't
want that.  If you want an object to respond to more messages
concurrently make more of them.

On 10/25/07, Peter William Lount <[hidden email]> wrote: