Peter William Lount wrote:
> I think it's best to let each developer-user choose how many native 
> threads per image and how many images are loaded and which images are 
> loaded. After all it's their program. Isn't our job as language and 
> systems designers to provide them with the tools that they need to build 
> the systems that they want to build? I think so. What do you think?

Everything you say, to the letter, can and has been said about manual 
memory management. 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. 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.

Cheers,
   - Andreas