2009/3/23 Antony Blakey <[email protected]>: > > On 23/03/2009, at 12:32 AM, Stéphane Ducasse wrote: > >> can you illustrate that point? > > It might be that Smalltalk and wide-spread immutability and > fundamentally incompatible. The problem is that Smalltalk's model has > Objects whose state changes in response to messages. Such state change > breaks immutability. But if objects are immutable, then the problem is > that after any mutation operation within a method, subsequent sends > need to be not to self, but to the newly mutated object. This problem > cascades, with the effective self needing to change potentially after > every send. Maybe the solution is to enable that to happen seamlessly > e.g. 'self' changes as the object mutates (because the object isn't > actually mutating). Objects do make immutability-based concurrency > more 'interesting'. > > It's important to note that Clojure is a rethinking of Lisp, and the > end result is not Common Lisp + concurrency + Java interop. I suspect > that a rethinking of Smalltalk would be similarly different than what > we now know. This doesn't surprise me - out assumptions about > concurrency, or the lack of it, and general inexperience with taming > true concurrency, is a significant context the design of most existing > languages, with notable exceptions such as CSP/Occam. > > Maybe the appropriate concurrency model for Smalltalk IS an ultra- > lightweight fine-grained copy-on-write multiple image model, with that > being the *only* threading abstraction. If you could control the > separation e.g. share some objects with well defined concurrency > semantics like Clojure such STM/Refs/Agents etc, then that might be > the best fit. OTOH a shared-nothing model would give you CSP/Erlang. > The implementation challenges are very different, and I must admit I > don't know enough about Hydra to know if that project has solved this > issue. >
Hydra simply runs separate object memories in separate native threads. This is clearly share nothing approach. The only win comparing to running multiple OS processes is the ability to establish a fast communication between them, as well, as in future, relax the 'share-nothing' relation towards partial sharing(islands/vats/micro-images). This i think would be best way to go, which would require minimal changes to language side. It is also good, because it is quite incremental i.e. you don't have to rewrite the whole smalltalk from scratch. -------- Now about other replies in topic by different people: Antony right: mutexes, semaphores, critical sections - this is simply doesn't scales! Forget about it! Leave these constructs to java & C/C++ , they are existing for more than 10 years in operating systems and their limitations are well known :) immutability - at a large scale, like automatic copy-on-write magic IMO would be a waste. And besides, smalltalk is one of the languages who says NO to magic. That's why i like it so much. :) > Antony Blakey > ------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > He who would make his own liberty secure, must guard even his enemy > from repression. > -- Thomas Paine > > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
