On 10/25/07, Peter William Lount <peter at smalltalk.org> wrote:
>
>  You're splitting hairs with my use of English.

I was under the impression you were a native English speaker.  Am I incorrect?

> The vast majority of
> concurrency problems won't fit well with the process-based model of
> concurrency (of Erlang and other systems).
>
>  Process-based model of concurrency won't solve ALL the problems.

And here another jump.  It wont solve *the vast majority* or it wont
solve *all*?  Which is it?

> Consider
> that there are an infinite number of concurrency problems. You're telling me
> that the solution you are proposing solves them all?

No!  Again, will you please stop asking me to defend statements *you made*???

> Please don't force ill
> conceived deep copying solutions upon us as the ONLY solution.

Who is forcing anything on anyone?  I'm pointing out what I thought
(prior to this thread) was already obvious:  shared state locking
can't scale.  The fact is, Squeak already *has* futures in several
incarnations, shared state locking in various incarnations and so on.

I'm simply pointing out that adding true threading like Java has to
Squeak is a pour use of resources we don't have.

>  One solution won't fit all.

And too many unnecessary choices produce indecision and worse.

Options are good.  Too many options are less good.  Bad options are
bad.  Look at C++.

>  No, sharing memory does not necessarily break encapsulation. Many things
> break encapsulation for sure. Blocks for one (see Alan Kay's comments on
> this).

Of course it does.  Two separate entities that "own" the same resource
at the same time.

>  I provide an example and one way (of many ways) to solve it. Yes. That's
> being responsible from my perspective since I know the a solution that will
> work I'm not going to hide it as some sort of covert test.

That's fine to do, but you seem to assume there is no other solution
and therefor Actor-style message passing can't handle it.

>  The point or "what does it prove" is that no one concurrency solution will
> solve all the problems. I provided an example to show that and to show the
> kind of nasty problem that other concurrency problems can solve.

And what exactly is going to solve this problem?  Shared state
fine-grained locking?  Across 10k nodes!  You can't be serious.

>  I work quite hard to implement more power and capability for Smalltalk not
> take it away. Altering the Smalltalk language - or even one version of it,
> Squeak - in such a way as to make it less powerful by removing concurrency
> control capabilities isn't going to fly with me and a large number of users
> of Squeak.

And this is the funniest part.  The current model we have
(shared-state) is the weakest of the models.