I'm a lot more interested in architectures that scale well on both
multi-core machines and across blade servers, data centers and clouds than
in multi-threaded architectures that may (or may not) scale on a single
address space.   A multi-threaded image comes up short here when compared to
Erlang-like approaches.

-david

On Mon, Jul 7, 2008 at 1:07 AM, Jason Johnson <jason.johnson.081 at gmail.com>
wrote:

> On Mon, Jul 7, 2008 at 8:00 AM, Peter William Lount <peter at smalltalk.org>
> wrote:
> > Hi,
> >
> > I get that you think that it's a clean model for concurrency. I don't buy
> it
> > though.
> >
> > Please describe it fully and in detail. Thank you.
>
> Why does he need to describe this again?  You could look at past
> threads or you could look at some of the *actual research on this
> subject*.  Here is a paper from 2006:
>
> "The problem with threads"
> http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html
>
> > You'll allow multiple non-native smalltalk green threads right?
>
> I wouldn't.  This is a big source of bugs and confusion.  I would
> personally change the ST process model to have "processes" instead of
> "threads" (i.e. nothing is shared between them).
>
> > Your "simplified" model doesn't seem to be simple at all. You'd have to
> > prevent any green threads within the native thread.
> >
> > You then push the concurrency processing problems off on to multiple
> images
> > and now the problems become data base like concurrency issues and
> > serialization issues and object identity/version issues.
> >
> > You've not gained much and you've limited others needs in the process.
>
> Here you just seem to be going off on a tangent without even knowing
> what solution he had in mind.  Wonderfully productive way to argue.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080707/c84b9196/attachment.htm