On Wed, May 12, 2010 at 8:57 PM, Alex Elsayed wrote:
> Forgot to send this to the list.
>
> -- Forwarded message --
> From: Alex Elsayed ...
>
It's also CPS based, which fits pretty well.
>
Here's another, one that might fit more readily with perlesque/CLR:
Actors that Unify T
Forgot to send this to the list.
-- Forwarded message --
From: Alex Elsayed
Date: Wed, May 12, 2010 at 8:55 PM
Subject: Re: Ideas for a "Object-Belongs-to-Thread" threading model
To: Daniel Ruoso
You may find interesting a paper that was (at one point) listed
in the /topic of #
Em Qua, 2010-05-12 às 10:12 -0700, Dave Whipp escreveu:
> Before discussing the implementation, I think it's worth while
> stating
> what it is that you are attempting to abstract. For example, is the
> abstraction intended for a mapping down to a GPU (e.g. OpenCL) with a
> hierarchical address
Daniel Ruoso wrote:
Hi,
The threading model topic still needs lots of thinking, so I decided to
try out some ideas.
Every concurrency model has its advantages and drawbacks, I've been
wondering about this ideas for a while now and I think I finally have a
sketch. My primary concerns were:
1 -
I might have some more to say about any threading model later, but for
now I wanted to make everyone aware of a scripting language that is
"truly" multi-threaded - you may want to check it out. Some of it's
syntax is Perlish, whereas some is not - the point is that it is
supposed to scale on SMP ma
Em Ter, 2010-05-11 às 21:45 -0300, Daniel Ruoso escreveu:
> he threading model topic still needs lots of thinking, so I decided to
> try out some ideas.
After I sent the second version, I just realized I could make it simpler
by just assuming "one OS thread per Coroutine Group"... so here goes the
Em Ter, 2010-05-11 às 21:45 -0300, Daniel Ruoso escreveu:
> The threading model topic still needs lots of thinking, so I decided to
> try out some ideas.
After BrowserUK feedback and some more reading (including
http://www.c2.com/cgi/wiki?MessagePassingConcurrency ) and links from
there on, I deci
BrowserUK wrote:
> > -there are the interpreter processes.
> > Inventing (overloaded) terminology will just create confusion. Very
> > unhelpful in a context that suffers more than its fair share already.
Okay, I should probably call them "Actors" to use a more precise
terminology - since this