On Wed, Dec 17, 2008 at 10:19:07AM -0300, Daniel Ruoso wrote:
> Em Qua, 2008-12-17 ??s 23:35 +1100, Timothy S. Nelson escreveu:
> > On Wed, 17 Dec 2008, Daniel Ruoso wrote:
> > > Em Qua, 2008-12-17 ??s 15:00 +1100, Timothy S. Nelson escreveu:
> > >> My basic assumption is that there's goin
simple, easy to look at, and not overly
complicated with meaning or cleverness.
my $0.02.
Brett
--
B. Estrade
http://www.loni.org
; role if it should be
> cloned instead of being proxied through a "RemoteValue" when sent
> in a "RemoteInvocation".
>
> 11 - The "MessageQueue" notifies the scheduler whenever new data is
> available in that queue so the target coroutine might be raised.
>
> 12 - Exception handling gets a bit hairy, since exceptions might only
> be raised at the calling scope when the value is consumed.
>
> 13 - List assignment and Sink context might result in synchronized
> behavior.
>
> comments are appreciated...
>
> daniel
>
--
B. Estrade
> >imagine that a FIFO object might have a "put" role and a "get" role
> >that producer/consumer clients would (temporarily) own while using
> >(note that granting of ownership may imply arbitration, and later
> >forced-revocation if the resource-ownership is not released/extended
> >before some timeout expires). It may be wrong to conflate "role" as a
> >unit of reuse with "role" as an owned window onto a subset of an
> >object's methods.
> >
> >Perl6 has a set of language primitives to support various aspects of
> >concurrency. It is indeed interesting to consider how these map ot
> >vastly difference computation platforms: OpenCl Vs OpenMP Vs Cloud. It
> >deeps a little premature to be defining roles (e.g. RemoteInvocation)
> >without defining the mapping of the core operators to these various
> >models of computation.
> >
> >
> >Dave.
--
B. Estrade
; This has been one of the secret sauces of the Perl 6 redesign, to
> hang every piece of information on the peg where it belongs, and not
> somewhere else. And that is why threading of *any* kind will work
> much better in Perl 6.
>
> Larry
--
B. Estrade
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 wrote:
>
> >On Fri, May 14, 2010 at 12:27:18PM +0100, nigelsande...@btconnect.com
> >wrote:
> >>On Fri, 14 May 2010 10:01:41 +0100, R
isten to some good
> music whilst they put the needle in".
>
> >
> >Rather fork-join!
>
> For platforms where fork is native, it doesn't go away just because
> threads support is present.
>
> >
> >(Do Perl_6 hyper-operators need pthreads?)
> >
>
> Buk.
--
B. Estrade
it over explicit concurrency wherever possible.
I know you're speaking about the Perl interface to concurrency, but
you seem to contradict yourself because message passing is explicit
whereas shared memory is implicit - two different models, both of
which could be used together to implement a pretty flexible system.
It'd be a shame to not provide a way to both use threads directly or
to fallback to some implicitly concurrent constructs.
Brett
--
B. Estrade
s of
> problems I work on, I'm well aware that I'm not the right person to help
> in this design work. We need those poor souls who already suffer under
> threads to share their tales of constant misery (and their occasional
> moments of triumph) so we can identify successful patterns of use
> and steal^Wborg^Wborrow the very best available solutions.
Are you sure you couldn't use threading over shared memory? :)
Cheers,
Brett
>
> Damian
--
B. Estrade
ot;won't have side
> effects" is tricky at best, squeezed in as we are between &eval,
> exuberant dynamism, and the Halting Problem.
If one knows what variables are shared, some degree of side effect
potential can be determined. But yes, in general, a tough problem.
Brett
>
> // Carl
--
B. Estrade
to a lot of different things, but the problem is
now not only implementing an algorithm concurrently but also using the
concurrency available in the hardware efficiently.
Brett
>
>
>
>
>
>
>
> --
> Mark J. Reed
--
B. Estrade
First, yes, Perl 6 is awesome. Everything that's come out as a result
of this effort is awesome. The rest is inline below.
On Fri, May 25, 2012 at 10:32:35AM +0200, Moritz Lenz wrote:
> Hallo Parrot,
>
> we are well aware that the documentation for Perl 6 is quite lacking.
> Any contributions i
On Mon, May 28, 2012 at 03:38:48PM +0800, Xiao Yafeng wrote:
> On Sat, May 26, 2012 at 6:34 PM, Nicholas Clark wrote:
>
> > On Fri, May 25, 2012 at 08:44:30AM -0500, B. Estrade wrote:
> >
> >
> > Realistically, that's not going to happen. The internals of
Oh, how sad. I recall fondly when it was first announced during the heyday of
Pugs. I even had an account on there.
Thank you for the resource ... And the stroll down memory lane.
Brett
Sent from my iPhone
> On Feb 28, 2015, at 9:22 AM, Juerd Waalboer wrote:
>
> Hi all,
>
> Just a short mes
14 matches
Mail list logo
