Igor Stasenko a écrit :
> 
> I'd like to hear more critics about such model :) If it proves to be
> viable and much or less easily doable (comparing to other models) then
> i could start working on it :)
> 

Hi Igor, I like your approach.
Main problem I see is that a lot of methods in current image are not 
multi-process safe!
Imagine one SortedCollection, one Process iterates on it, another add to 
it. Even now, with a single threaded image, you have to care! (see 
http://bugs.squeak.org/view.php?id=6030).

Exactly the OrderedCollection counter argument you served to Andreas!
Except Andreas knows he has to carefully choose shared states, and also 
has explicit futures and promises he is using sparingly, and can 
identify easily.

Your users will need atomic operations.
Thus you have to introduce another state attached to receiver object 
telling that you can read concurrently, but not put a write lock on it.
(in fact, you have 3 states, read-locked <-> free <-> write-locked)

 From pragmatic POV, prepare to put atomic blocks everywhere before 
having something usable! (maybe an <#atomic> pragma to be lighter).
You cannot simply state "that's a programmer problem, I provide the 
framework".
Bugs might occur from time to time, very hard to debug ones!
And your framework won't help much.

Beside, your users will have to deal with deadlock cases too...
We'd better start thinking of automatic deadlock detection...

Nicolas