-passing concurrency. This
balance will be implemented by modules.
comments are appreciated.
daniel
attachment: Perl6ThreadingModel.svg
--- Forwarded message ---
From: nigelsande...@btconnect.com
To: Dave Whipp - d...@whipp.name
+nntp+browseruk+e66dbbe0cf.dave#whipp.n...@spamgourmet.com
Cc:
Subject: Re: Parallelism and Concurrency was Re: Ideas for
aObject-Belongs-to-Thread (nntp: message 4 of 20) threading model
Em Dom, 2010-05-16 às 19:34 +0100, nigelsande...@btconnect.com escreveu:
3) The tough-y: Closed-over variables.
These are tough because it exposes lexicals to sharing, but they are so
natural to use, it is hard to suggest banning their use in concurrent
routines.
This is the point I
On Tue, 18 May 2010 11:39:04 +0100, Daniel Ruoso dan...@ruoso.com wrote:
This is the point I was trying to address, actually. Having *only*
explicitly shared variables makes it very cumbersome to write threaded
code, specially because explicitly shared variables have a lot of
restrictions on
concurrency model.
If we drop that requirement then we can simply go to the
we-can-spawn-as-many-os-threads-as-we-want model..
I do not see that as a requirement. But, I am painfully aware that I am
playing catchup with all the various versions, flavours and colors of
Perl6 interpreter. And more
Em Ter, 2010-05-18 às 12:58 -0700, Alex Elsayed escreveu:
You are imposing a false dichotomy here. Neither 'green' threads nor kernel
threads preclude each other. In fact, it can be convincingly argued that they
work _best_ when combined. Please look at the GSoC proposal for hybrid
threading
nigelsande...@btconnect.com wrote:
There are very few algorithms that actually benefit from using even low
hundreds of threads, let alone thousands. The ability of Erlang (and go
an IO and many others) to spawn 100,000 threads makes an impressive demo
for the uninitiated, but finding
:
The important thing is not the number of algorithms: it's the number
programs and workloads.
From that statement, you do not appear to understand the subject matter of
this thread: Perl 6 concurrency model.
That seems a tad more confrontational than was required. It's also arguably
incorrect
nigelsande...@btconnect.com wrote:
From that statement, you do not appear to understand the subject matter
of this thread: Perl 6 concurrency model.
If I misunderstood then I apologize: I had thought that the subject was
the underlying abstractions of parallelism and concurrency that perl6
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,
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
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
Em Sex, 2010-05-14 às 18:13 +0100, nigelsande...@btconnect.com escreveu:
The point I(we)'ve been trying to make is that once you have a reentrant
interpreter, and the ability to spawn one in an OS thread,
all the other bits can be built on top. But unless you have that ability,
whilst the
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,
the
connection was opened. Is this possible with the concurrency model you
specified?
The things you're describing are from the time when we were assuming STM
(Software Transactional Memory) would be used by every implementation of
Perl 6. Things have changed a bit in the last months, as STM
roll things back like they were before the
connection was opened. Is this possible with the concurrency model you
specified?
The things you're describing are from the time when we were assuming STM
(Software Transactional Memory) would be used by every implementation of
Perl 6. Things have
Hi. I have a question for the S17-concurrency people.
Say I wanted to write a POP3 server. I want to receive a username and
password from the client. I want things to be interruptable during this, but
it's also impossible to sensibly roll things back like they were before
This last SOTO re-reminded me of what an inveterate fan I am of Perl 6. Wow.
My question today is about concurrency. I can imagine how things like IPC
Mailboxes (e.g. RFC 86) happen in modules. I can also imagine why Threads
(e.g. RFC 1) should be in modules- given the obvious dependence
I'll try to reply as good as possible, but I'm sure others will do better.
David Brunton wrote:
This last SOTO re-reminded me of what an inveterate fan I am of Perl 6. Wow.
My question today is about concurrency. I can imagine how things like IPC
Mailboxes
(e.g. RFC 86) happen
Jonathan Scott Duff [EMAIL PROTECTED] wrote:
On Thu, Jun 01, 2006 at 02:22:12PM -0700, Jonathan Lang wrote:
Forgive this ignorant soul; but what is STM?
Software Transaction Memory
Well, Software Transactional Memory if I'm being picky. :-) Some info and
an interesting paper here:-
At 1:50 PM -0700 6/1/06, Larry Wall wrote:
As for side-effecty ops, many of them can just be a promise to perform
the op later when the transaction is committed, I suspect.
Yes, but it would be important to specify that by the time control is
returned to whatever invoked the op, that any side
Darren Duncan schreef:
Each time a context (a code block, either a routine or a syntactic
construct like 'try' is) is entered that is marked 'is atomic', a new
transaction begins, which as a whole can later be committed or rolled
back; it implicitly commits if that context is exited normally,
On Thu, Jun 01, 2006 at 11:52:59AM +1200, Sam Vilain wrote:
: The lock on entry approach will only be for non-threaded interpreters
: that don't know how to do real STM.
The way I see it, the fundamental difference is that with ordinary
locking, you're locking in real time, whereas with STM you
Larry Wall wrote:
The way I see it, the fundamental difference is that with ordinary
locking, you're locking in real time, whereas with STM you potentially
have the ability to virtualize time to see if there's a way to order
the locks in virtual time such that they still make sense. Then you
On Thu, Jun 01, 2006 at 02:22:12PM -0700, Jonathan Lang wrote:
Larry Wall wrote:
The way I see it, the fundamental difference is that with ordinary
locking, you're locking in real time, whereas with STM you potentially
have the ability to virtualize time to see if there's a way to order
the
How does an atomic block differ from one in which all variables are
implicitly hypotheticalized? I'm thinking that a retry exit
statement may be redundant; instead, why not just go with the existing
mechanisms for successful vs. failed block termination, with the minor
modification that when an
How does an atomic block differ from one in which all variables are
implicitly hypotheticalized?
I assume that the atomicness being controlled by some kind of lock on
entry, it also applies to I/O and other side-effecty things that you
can't undo.
--
Hats are no worse for being made by ancient
Jonathan Lang wrote:
How does an atomic block differ from one in which all variables are
implicitly hypotheticalized? I'm thinking that a retry exit
statement may be redundant; instead, why not just go with the existing
mechanisms for successful vs. failed block termination, with the minor
Daniel Hulme wrote:
How does an atomic block differ from one in which all variables are
implicitly hypotheticalized?
I assume that the atomicness being controlled by some kind of lock on
entry, it also applies to I/O and other side-effecty things that you
can't undo.
The lock on entry
At 11:51 AM +1200 6/1/06, Sam Vilain wrote:
I think the answer lies in the checkpointing references in that
document. I don't know whether that's akin to a SQL savepoint (ie, a
point mid-transaction that can be rolled back to, without committing the
entire transaction) or more like a
31 matches
Mail list logo
