On 10/25/07, Peter William Lount peter@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.