Hi,

>     Everything you say, to the letter, can and has been said about
>     manual memory management. 
>

Not in my view.


>     The point you're apparently not getting is that the "one native
>     thread per image" is not only a workaround to avoid some very
>     nasty issues down in the VM, it also provides a clean *model* for
>     concurrency. 
>
I do get that you guys think that.


>     No such model exists for shared state concurrency which is the
>     real problem - since all synchronization is manual, it is pretty
>     much impossible to write large scalable systems correctly with
>     manual locks and mutexes. Just as it is impossible to write large
>     scalable systems correctly with manual memory management.
>

No, it's not impossible as evidenced by many large systems written in 
C++ and other languages without automatic garbage collection.

Automatic synchronization is a hot field of research.


>
>
> It's not *that* hard to write a large, scalable, concurrent systems 
> using Processes and Semaphores. Sure, at times it can be difficult 
> with horrible bugs that take a decade to manifest, but if you use 
> consistent patterns and encapsulate complex behaviour well, it is 
> quite tractable.
I concur.

One of my points is that it's one thing to say we simply doing it this 
one particular way and quite another to assert it can't be done when 
there is a Smalltalk that has done it (Smalltalk MT).

All the best,

Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080706/cbfc549c/attachment.htm