On Tue, 18 May 2010 11:41:08 +0100, Daniel Ruoso wrote:
Em Dom, 2010-05-16 às 19:34 +0100, nigelsande...@btconnect.com escreveu:
Interoperability with Perl 5 and
is reference counting should not be a high priority in the decision
making
process for defining the Perl 6 concurrency model.
I
On Tue, 18 May 2010 11:39:04 +0100, Daniel Ruoso 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 what they can be (t
--- 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
a"Object-Belongs-to-Thread" (nntp: message 4 of 20) threading mo
--- Forwarded message ---
From: nigelsande...@btconnect.com
To: "Dave Whipp - dave_wh...@yahoo.com"
<+nntp+browseruk+2dcf7cf254.dave_whipp#yahoo@spamgourmet.com>, "Dave
Whipp - d...@whipp.name"
<+nntp+browseruk+e66dbbe0cf.dave#whipp.n...@spamgourmet.com>
Cc:
Subject: Re: Paral
On Mon, 17 May 2010 17:20:28 +0100, Dave Whipp - d...@dave.whipp.name
<+nntp+browseruk+a2ac8a2dcb.dpuu#dave.whipp.n...@spamgourmet.com> wrote:
nigelsande...@btconnect.com wrote:
There are very few algorithms that actually benefit from using even low
hundreds of threads, let alone thousands.
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, w
On Fri, 14 May 2010 20:00:01 +0100, Daniel Ruoso - dan...@ruoso.com
<+nntp+browseruk+d52dbf78bb.daniel#ruoso@spamgourmet.com> wrote:
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
interprete
On Fri, 14 May 2010 15:58:00 +0100, Daniel Ruoso - dan...@ruoso.com
<+nntp+browseruk+d52dbf78bb.daniel#ruoso@spamgourmet.com> wrote:
Em Sex, 2010-05-14 às 15:48 +0400, Richard Hainsworth escreveu:
The less, or rather the more abstract, the specification in perl6, the
less likely perl6 wil
On Fri, 14 May 2010 15:05:44 +0100, B. Estrade 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> wrote:
>
>The suppo
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
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 wrote:
I have 3 main problems with your thinking.
1: You are conflating two fundamentally differe
27/02/2004 10:30:22, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>
>> Compiler version:
>>
>> Microsoft (R) 32-bit C/C++ Standard Compiler Version 13.00.9466 for 80x86
>
>Thanks update.
>
>
>> t\op\00ff-dos.t 255 65280 24 200.00% 1-2
>
>Strange
>
I've sent
On Thu, 26 Feb 2004 09:29:59 +0100, [EMAIL PROTECTED] (Leopold Toetsch) wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> > Please help me fill out the blanks by sending or committing patches.
> > Please make sure to have the latest and best Parrot from CVS.
Here (and attached) is summary of
On Wed, 25 Feb 2004 10:30:24 +0100, [EMAIL PROTECTED] (Leopold Toetsch) wrote:
> [EMAIL PROTECTED] (via RT) wrote:
>
> > The following corrects my poor memory handling
> > pointed out by mrnobo1024 at
> >
> > news://nntp.perl.org/perl.perl6.internals/21454
>
> Thanks, applied,
> leo
>
Leo,
All
I'm struggling to get up to speed on contributing to parrot and I have various
questions:
1) Is there any way past this problem?
cvs -d :pserver:[EMAIL PROTECTED]:/cvs/public co parrot
...
...
U parrot/ops/var.ops
cvs server: Updating parrot/pf
U parrot/pf/pf_ite
On Fri, 23 Jan 2004 10:24:30 -0500, [EMAIL PROTECTED] (Dan Sugalski) wrote:
> If you're accessing shared data, it has
> to be locked. There's no getting around that. The only way to reduce
> locking overhead is to reduce the amount of data that needs locking.
>
One slight modification I would m
The subject says it all.
As parrot is designed to be targetted by many langauges,
how will it handle 'eval' opcodes for those different languages?
Shell out to a seperate process?
Nigel.
21/01/2004 02:12:09, Gordon Henriksen <[EMAIL PROTECTED]> wrote:
> This is false. The mark phase will still need to run over the entire
> process, else it cannot detect all references into the pool.
>
If by reference, you mean address, then that is true.
If when a reference is taken, the addres
20/01/2004 13:29:35, Gordon Henriksen <[EMAIL PROTECTED]> wrote:
>On Monday, January 19, 2004, at 07:58 , [EMAIL PROTECTED]
>wrote:
>
>> Is there any likelyhood that memory allocation will be hidden behind
>> macros at two levels:
>> - ALLOCPOOL() for allocating large chunks of memory (ppols) t
> =item MUTEX
>
> This is a low level, under the hood, not exposed to users, thing that
> can be locked. They're non-recursive, non-read/write, exclusive
> things. When a thread gets a mutex, any other attempt to get that
> mutex will block until the owning thread releases the mutex. The
> platfor
On Fri, 16 Jan 2004 08:09:58 +0100, [EMAIL PROTECTED] (Leopold Toetsch) wrote:
> I don't know, if we should depend on that, but it would definitely help.
> Could some Windows guys have a look at:
> http://www.microsoft.com/windows/sfu/
>
>
> [Interoperability. Integration. Extensibility.]
> Wind
21 matches
Mail list logo
