Jason it's a good proposal.
For my part today, with the help of a friend of mine, I think I've found a
conceptual problem on the model I was exploring so I have to (re)think if it
continues to be valid at all.
Cheers,
Sebastian
PS: it's not about it's overhead nor hardware resources.
> -----Mensaje original-----
> De:
[hidden email]
> [mailto:
[hidden email]] En
> nombre de Jason Johnson
> Enviado el: Viernes, 26 de Octubre de 2007 01:39
> Para:
[hidden email]; The general-purpose Squeak developers list
> Asunto: Concurrency problems/solutions (was Re: Multy-core CPUs)
>
> Hi all,
>
> There has been a lot of discussion about concurrency, and
> what tends to happen is we all have ideas in our head of what
> we want solved and why a given solution can/can't solve it.
>
> So what I propose is, we come up with concurrency problems
> and then how we would solve them in the different
> methodologies. With code. :)
>
> Of course it is important to be specific. An example is the
> "million node" problem highlighted by Peter. I would need to
> know what this data is, where it comes from and so on so I
> can determine if any one node should *ever* have the graph at once.
>
> This is another challenge, it will be tempting to make
> assumptions about what can be done with the data. Please
> don't. :) You may have some reason you think the data can't
> be partitioned, but perhaps it can.
>
> I'm curious to see how other solutions solve the various
> problems out there, and before I go do a bunch of work on the
> Actor model I would love to see if there are any cases it
> really can't deal with.
>
> Thanks,
> Jason
>