Hi,

Andreas Raab: "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 get that you think that it's a clean model for concurrency. I don't 
buy it though.

Please describe it fully and in detail. Thank you.

You'll allow multiple non-native smalltalk green threads right? If yes, 
then it's not solving anything as we know from working on very large 
single native threaded deployed Smalltalk systems that have even a 
modest number (10 through 25) of threads running at one time.

Your "simplified" model doesn't seem to be simple at all. You'd have to 
prevent any green threads within the native thread.

You then push the concurrency processing problems off on to multiple 
images and now the problems become data base like concurrency issues and 
serialization issues and object identity/version issues.

You've not gained much and you've limited others needs in the process.

You can certainly accomplish your goals with a general purpose N native 
threads per image by simply setting an image level configuration 
property that would limit the native threads to 1 for that image.

All the best,

Peter William Lount
[ | peter at smalltalk dot org ]