I don't know if mapping Smalltalk processes to native threads is the way to go, given the pain I've seen in the Java and C# space.

What might be interesting is to develop low-level primitives (along the lines of the famed map/reduce operations) that provide parallel processing versions of commonly used collection functions.

No idea how easy this would be to do, but on the surface seems more promising than trying to do process/thread jiggery pokery.

Steve

On 10/17/07, Sebastian Sastre <ssastre@seaswork.com> wrote:
This is not my area but I imagine that somehow Squeak processes should map
to OS native threads paralellizable by each of the cores. Any chance to
Exupery be of some help on that? I ask because if it is then is a must for
that future.

        regards,

Sebastian Sastre


> -----Mensaje original-----
> De: squeak-dev-bounces@lists.squeakfoundation.org
> [mailto:squeak-dev-bounces@lists.squeakfoundation.org] En
> nombre de gruntfuttuck
> Enviado el: Miércoles, 17 de Octubre de 2007 06:10
> Para: squeak-dev@lists.squeakfoundation.org
> Asunto: Multy-core CPUs
>
>
> How is squeak going to handle multy-core CPUs, if at all? If
> we see cores of 100 plus in the future and squeak stay as it
> is, I would imagine other languages such as erlang, will look
> more attractive.
> --
> View this message in context:
> http://www.nabble.com/Multy-core-CPUs-tf4639074.html#a13249733
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>
>