On 22/03/2009, at 9:48 PM, Igor Stasenko wrote: > Sorry, my fault. You need to sync in both cases (even with green > threads).
Green threads make some underlying implementation details easier, but at the language level the difference they make is determined by the interleaving guarantees they provide, and the extent to which the user can take advantage of those guarantees e.g. the yield-point model. IMO the solution to concurrency is not to simply add native threads - it also requires a more functional type of programming, and that can be largely provided by immutable data structures and more powerful abstractions, such as those provided in Clojure. I'm not suggesting adding native threads to Squeak. Squeak is quite a minefield as it is. I think it's time for a new model of Smalltalk that includes native threads from the get-go, and is a rethinking of the Smalltalk tradition, in the same way that Clojure is a rethinking of the Lisp tradition. The parallels between Lisp and Smalltalk, in terms of their paradigmatic roles, market issues, and communities, is quite striking. Why should these two powerhouses of beautiful programming not *both* be reborn. > There is another problem, that squeak processes is cheap (few bytes in > object memory), while allocating new native thread consumes > considerable amount of memory & address space. So, if you map > Processes to native threads, you will lose the ability in having > millions of them, instead you will be limited to thousands. You don't need a 1:1 mapping. You can use a native thread pool to execute lightweight threads. Erlang manages with huge numbers of language level processes. Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead. -- Thomas Jefferson _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
