On Mon, Mar 23, 2009 at 12:49 AM, Antony Blakey <[email protected]>wrote:
> > 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. Anybody who relies on the behaviour of the scheduler deserves to be forced to program in BASIC. Semaphores work; use them. > > > 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. Smalltalk, the language rather than the implementation, already has fantastic support for concurrency. Smalltalkers just don't know how to use it. We don't need to rethink the model, we just need to learn to use what we have. > > > 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. > I agree here. Gulik. -- http://gulik.pbwiki.com/
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
