On Wed, Oct 13, 2010 at 12:46 AM, Tim Bunce wrote:
> So I'd like to use this sub-thread to try to identify when lessons we
> can learn from ithreads. My initial thoughts are:
>
> - Don't clone a live interpreter.
> Start a new thread with a fresh interpreter.
>
> - Don't try to share mutable da
I agree that threads are generelly a difficult issue to cope. What is
worse, there are a lot of Java-developers who tell us, that it is not
difficult for them,
but in the end the software fails on the productive system, for example
because the load is different then on the test system, causing dif
Damian Conway wrote:
Perhaps we need to think more Perlishly and reframe the entire question.
Not: "What threading model do we need?", but: "What kinds of non-sequential
programming tasks do we want to make easy...and how would we like to be
able to specify those tasks?"
The mindset that I u
On Tue, Oct 12, 2010 at 10:28 PM, B. Estrade wrote:
>> I agree. I would prefer implicit 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
On Tue, Oct 12, 2010 at 4:22 PM, Damian Conway wrote:
> The problem is: while most people can agree on what have proved to be
> unsatisfactory threading models, not many people can seem to agree on
> what would constititute a satisfactory threading model (or, possibly, models).
>
> What we really
When Larry decided that Perl 6 would incorporate concepts from
prototype-based objects, he did so at least in part because it's more
intuitive for people to work with, e.g., "a cow" than it is to try to
work with "the concept of a cow" as a thing unto itself. In a similar
way, I think that Perl's
Carl (>):
> == About C<.perl>
>
> The choice here was between letting C<.perl> display only public
> attributes, or keeping it the way it is, displaying public as well as
> private attributes. The former is potentially a great help for
> debugging; the latter respects the normal-OO level of privacy
Logbot (>):
> [S12] spec setting and getting values of attributes by means of introspection
>
> After lengthy IRC discussion, we concluded that it's a good idea to provide
> some form of introspection that doesn't bother about perceived privacy
> borders, provided that the implementation makes it f
On Tue, Oct 12, 2010 at 07:22:33AM -0700, Damian Conway wrote:
> What we really need is some anecdotal evidence from folks who are actually
> using threading in real-world situations (in *any* languages). What has worked
> in practice? What has worked well? What was painful? What was error-prone?
>
Damian, I use threads in C++ a lot in my day to day job. We use an
in-house library which isn't much more than a thread class which you
inherit from and give a Run method to, and a load of locks of various
(sometimes ill-defined) kinds.
Let me say: it's not good. Threads with semaphores and mutexe
Although anecdotal, I've heard good things about Go's "channel" mechanism as a
simple lightweight concurrency model and a good alternative to typical
threading. Channels are first-class in the language and leverage simple
"goroutine" semantics to invoke concurrency.
--- Phil
-Original M
Leon Timmermans wrote:
> For the love of $DEITY, let's please not repeat ithreads!
$AMEN!
Backwards compatibility is not the major design criterion for Perl 6,
so there's no need to recapitulate our own phylogeny here.
The problem is: while most people can agree on what have proved to be
unsati
On Mon, Oct 11, 2010 at 12:32 AM, Ben Goldberg wrote:
> If thread-unsafe subroutines are called, then something like ithreads
> might be used.
For the love of $DEITY, let's please not repeat ithreads!
Branch: refs/heads/master
Home: http://github.com/perl6/specs
Commit: 00572dd42250299c2d35d1735691cf5f2601c666
http://github.com/perl6/specs/commit/00572dd42250299c2d35d1735691cf5f2601c666
Author: Carl Masak
Date: 2010-10-12 (Tue, 12 Oct 2010)
Changed paths:
M S06-routines.pod
Log Me
Ben (>):
> If perl6 can statically (at compile time) analyse subroutines and
> methods and determine if they're reentrant, then it could
> automatically use the lightest weight threads when it knows that the
> entry sub won't have side effects or alter global data.
I'm often at the receiving end o
On Oct 6, 1:28 pm, nore...@github.com wrote:
> Branch: refs/heads/master
> Home: http://github.com/perl6/specs
>
> Commit: cb8c8487fa0ab7156fecffdc8a52bf75d4290c1b
> http://github.com/perl6/specs/commit/cb8c8487fa0ab7156fecffdc8a52bf75...
> Author: Carl Masak
> Date: 2010-10-06 (Wed, 06 Oct
Has there been any decision yet over what model(s) of threads perl6
will support?
Will they be POSIX-like? ithread-like? green-thread-like?
It is my hope that more than one model will be supported... something
that would allow the most lightweight threads possible to be used
where possible, and i
17 matches
Mail list logo
