On Fri, 14 May 2010 17:35:20 +0100, B. Estrade - estr...@gmail.com
+nntp+browseruk+c4c81fb0fa.estrabd#gmail@spamgourmet.com wrote:
The future is indeed multicore - or, rather, *many-core. What this
means is that however the hardware jockeys have to strap them together
on a single node,
Jason Switzer wrote:
On Thu, May 13, 2010 at 3:59 AM, nigelsande...@btconnect.com wrote:
And at the core of that, is the need for preemptive (kernel) threading and
shared memory.
These can (and should!) be hidden from the application programmer, through
the use of language and/or library
Ruud ():
(Do Perl_6 hyper-operators need pthreads?)
No. The ability to thread over list elements in a hyper operator is
more of a possibility than a requirement, if I understand things
correctly.
// Carl
On Fri, 14 May 2010 10:01:41 +0100, Ruud H.G. van Tol - rv...@isolution.nl
+nntp+browseruk+014f2ed3f9.rvtol#isolution...@spamgourmet.com wrote:
The support of threading should be completely optional. The threading
support should not be active by default.
I'd like to understand why you
After reading this thread and S17, I have lots of questions and some
remarks.
Parallelism and Concurrency could be considered to be two different things.
The hyperoperators and junctions imply, but do not require, parallelism.
It is left for the implementors to resolve whether a single or
On Fri, May 14, 2010 at 03:48:10PM +0400, Richard Hainsworth wrote:
: After reading this thread and S17, I have lots of questions and some
: remarks.
:
: Parallelism and Concurrency could be considered to be two different things.
:
: The hyperoperators and junctions imply, but do not require,
:
On Fri, 14 May 2010 15:05:44 +0100, B. Estrade estr...@gmail.com wrote:
On Fri, May 14, 2010 at 12:27:18PM +0100, nigelsande...@btconnect.com
wrote:
On Fri, 14 May 2010 10:01:41 +0100, Ruud H.G. van Tol -
rv...@isolution.nl
+nntp+browseruk+014f2ed3f9.rvtol#isolution...@spamgourmet.com
On Fri, May 14, 2010 at 03:48:10PM +0400, Richard Hainsworth wrote:
After reading this thread and S17, I have lots of questions and some
remarks.
Parallelism and Concurrency could be considered to be two different things.
The hyperoperators and junctions imply, but do not require,
On Fri, May 14, 2010 at 09:50:21AM -0700, Larry Wall wrote:
On Fri, May 14, 2010 at 03:48:10PM +0400, Richard Hainsworth wrote:
...snip
But as you say, this is not a simple problem to solve; our response
should not be to punt this to future generations, but to solve it
as best as we can,
On Fri, May 14, 2010 at 06:03:46PM +0100, nigelsande...@btconnect.com wrote:
On Fri, 14 May 2010 15:05:44 +0100, B. Estrade estr...@gmail.com wrote:
On Fri, May 14, 2010 at 12:27:18PM +0100, nigelsande...@btconnect.com
wrote:
On Fri, 14 May 2010 10:01:41 +0100, Ruud H.G. van Tol -
On Fri, May 14, 2010 at 12:27:18PM +0100, nigelsande...@btconnect.com wrote:
On Fri, 14 May 2010 10:01:41 +0100, Ruud H.G. van Tol - rv...@isolution.nl
+nntp+browseruk+014f2ed3f9.rvtol#isolution...@spamgourmet.com wrote:
The support of threading should be completely optional. The
This should be a reply to Daniel Ruoso's post above, but I cannot persuade
my nntp reader
to reply to a post made before I subscribed here. Sorry
On Wed, 12 May 2010 14:16:35 +0100, Daniel Ruoso dan...@ruoso.com wrote:
I have 3 main problems with your thinking.
1: You are conflating two
On Thu, May 13, 2010 at 3:59 AM, nigelsande...@btconnect.com wrote:
This should be a reply to Daniel Ruoso's post above, but I cannot persuade
my nntp reader
to reply to a post made before I subscribed here. Sorry
And at the core of that, is the need for preemptive (kernel) threading and
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 is
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
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
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
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
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
Forgot to send this to the list.
-- Forwarded message --
From: Alex Elsayed eternal...@gmail.com
Date: Wed, May 12, 2010 at 8:55 PM
Subject: Re: Ideas for a Object-Belongs-to-Thread threading model
To: Daniel Ruoso dan...@ruoso.com
You may find interesting a paper
On Wed, May 12, 2010 at 8:57 PM, Alex Elsayed eternal...@gmail.com wrote:
Forgot to send this to the list.
-- Forwarded message --
From: Alex Elsayed eternal...@gmail.com ...
It's also CPS based, which fits pretty well.
Here's another, one that might fit more readily with
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 - It can't require
Since I don't think BrowserUK subscribes here, I'll paste in the remarks
he attached to your earlier paste, just to help get the discussion going,
and on the assumption this will not be regarded as antisocial. :)
Larry
BrowserUK wrote:
-there are the interpreter processes.
Inventing
On Tue, 11 May 2010, Daniel Ruoso wrote:
2 - The interpreter implements a scheduler, just like POE.
I don't have a clue about threading, but I saw POE, and since I know
that's an event loop mechanism, I thought I'd comment that I want to be able
to do GTK programming, which I think
24 matches
Mail list logo
