Michael Lazzaro <[EMAIL PROTECTED]> writes:
> On Monday, May 26, 2003, at 06:10 PM, Dave Whipp wrote:
>> So, in summary, its good to have a clean abstraction for all the
>> HCCCT things. But I think it is a mistake to push them too
>> close. Each of the HCCCT things might be implemented as facades
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote in
> for {...}
>
> It doesn't matter whether foo() is a closure or function returning a
> list, lazy list, or iterator, or is a coroutine returning it's .next
> value. Which is excellent, and, I'd argue, the whole point; I'm not
> sure that we can
On Wednesday, May 28, 2003, at 02:56 PM, Austin Hastings wrote:
(s/coroutine/thread/g for the same rough arguments, e.g. "why should
the caller care if what they're doing invokes parallelization, so
long as it does the right thing?")
Global variables. Threads __never__ do the right thing.
Heh. Tha
"Austin Hastings" <[EMAIL PROTECTED]> wrote
> --- Dave Whipp <[EMAIL PROTECTED]> wrote:
> > "Austin Hastings" <[EMAIL PROTECTED]> wrote:
> > > 1. C always acts the same way -- stores args in
> > CurThread.result
> > > and gives up control to [?something?].
> >
> > I think you want a fifo on the out
> --- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
> >
> > On Wednesday, May 28, 2003, at 01:01 PM, Austin Hastings wrote:
> > > Exampling:
> > >
> > > sub traverse(Hash $tree) {
> > > return unless $tree;
> > >
> > > traverse $tree{left} if $tree{left};
> > > yield $tree{node};
> > > traver
> But, as Luke pointed out, some of the other syntax required to make
> that work is isn't particularly friendly:
>
> coro pre_traverse(%data) {
> yield %data{ value };
> yield $_ for <&_.clone(%data{ left })>;
> yield $_ for <&_.clone(%data{ right })>;
> }
>
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>
> On Wednesday, May 28, 2003, at 01:01 PM, Austin Hastings wrote:
> > Exampling:
> >
> > sub traverse(Hash $tree) {
> > return unless $tree;
> >
> > traverse $tree{left} if $tree{left};
> > yield $tree{node};
> > traverse $tree{right} if $t
On Wednesday, May 28, 2003, at 01:01 PM, Austin Hastings wrote:
Exampling:
sub traverse(Hash $tree) {
return unless $tree;
traverse $tree{left} if $tree{left};
yield $tree{node};
traverse $tree{right} if $tree{right};
}
my %hash is Tree;
my &cotrav := coro &traverse(%hash);
print $_ for ;
--- Dave Whipp <[EMAIL PROTECTED]> wrote:
> "Austin Hastings" <[EMAIL PROTECTED]> wrote:
> > 1. C always acts the same way -- stores args in
> CurThread.result
> > and gives up control to [?something?].
>
> I think you want a fifo on the output there -- at least conceptually.
> "Stores args in .r
You may evaluate for yourself whether thse comments are actually worth
two cents, but:
I want to be able to tell whether my program is threading or using some
other useful-but-not-what-I'd-do-in-a-hurry tool.
I don't want to learn a thousand different details that are only there
to make sure I k
"Austin Hastings" <[EMAIL PROTECTED]> wrote:
> 1. C always acts the same way -- stores args in CurThread.result
> and gives up control to [?something?].
I think you want a fifo on the output there -- at least conceptually.
"Stores args in .result" might overly block the producer thread.
"gives up
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>
> How, then, would you design an interface around (Concept 1) -- the
> listener/eventloop/subprocess model? Pseudocode for a top-level
> event
> loop might be something like:
>
> loop {
> sleep($fraction), next
>unless
On Tuesday, May 27, 2003, at 07:32 PM, Jonathan Scott Duff wrote:
On Tue, May 27, 2003 at 02:05:57PM -0700, Michael Lazzaro wrote:
If we could think about "threads" not in terms of forkyness, but
simply
in terms of coroutines that can be called in parallel, it should be
possible to create an imple
tree > { print }
(I've s/yield/emit/ to avoid mixing the control and data flow aspects)
This algorithm will work whether the "cothreads" are implemented as parallel
threads, or as coroutines. The difference is the scheduling policy. The
user-level difference is that one policy w
--- Dave Mitchell <[EMAIL PROTECTED]> wrote:
> On Wed, May 28, 2003 at 07:58:37AM -0700, Austin Hastings wrote:
> > On a single-CPU box, the OS level threads could easily be used to
> > support blocking operations feeding back to async I/O, while all
> "real
> > work" (execution of opcodes) was do
On Wed, May 28, 2003 at 07:58:37AM -0700, Austin Hastings wrote:
> On a single-CPU box, the OS level threads could easily be used to
> support blocking operations feeding back to async I/O, while all "real
> work" (execution of opcodes) was done in a single thread. Parrot could
> elect to implement
--- Dave Mitchell <[EMAIL PROTECTED]> wrote:
> On Tue, May 27, 2003 at 02:05:57PM -0700, Michael Lazzaro wrote:
> > If we could think about "threads" not in terms of forkyness, but
> simply
> > in terms of coroutines that can be called in parallel, it should be
>
> > possible to create an implem
On Tue, May 27, 2003 at 02:05:57PM -0700, Michael Lazzaro wrote:
> If we could think about "threads" not in terms of forkyness, but simply
> in terms of coroutines that can be called in parallel, it should be
> possible to create an implementation of "threading" that had to do a
> whole heck-of-
Quoting Michael Lazzaro <[EMAIL PROTECTED]>:
> Similarly, then, I would expect:
>
> sub foo(...) is threaded { ... yield() ... return() }
>
> foo(...args...)
>
> to start &foo as a new thread. C would temporarily suspend
> the thread, and C would end the thread. (Note that you could
Jonathan Scott Duff wrote:
I've read this post far more times than I care to admit and I still
see no merit to conflating "threads" and "coroutines".
To me, the salient feature of coroutines is the ability to start from
the beginning or from where we left off, while the salient feature of
threads
On Tue, May 27, 2003 at 02:05:57PM -0700, Michael Lazzaro wrote:
>
> On Tuesday, May 27, 2003, at 01:16 PM, Austin Hastings wrote:
> > I like and agree with some of what you've been saying. I too think that
> > there's a case of "an x is just a y with ..." underlying the whole
> > coro/thread/para
On Mon, May 26, 2003 at 11:54:46AM -0700, Michael Lazzaro wrote:
[ snip ]
> [1.4] Cothreads
>
> Consider a single programmatic entity that could handle the entire
> problem space described -- a single unit that represented all the most
> common usages of HCCCT.
I've rea
MikeL writes:
> > I say this because Damian's coroutine proposal could be greatly
> > simplified (IMHO making it clearer and easier) if calling the sub
> > didn't imply starting an implicit coroutine the first time. I might
> > write something that exemplifies this.
>
> I'd be quite interested in
"John Macdonald" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I would like to suggest a radically different
> mechanism, that there be operators: fork, tfork, and
> cfork to split off a process, thread, or coroutine
> respectively. (The first might be called pfork
> if we're will
Wow, what a flood.
The idea of keep the various degrees of code
parallelism similar in form yet distinct in detail
sounds good to me.
I would like to suggest a radically different
mechanism, that there be operators: fork, tfork, and
cfork to split off a process, thread, or coroutine
respectively.
A few more random thoughts:
Austin proposed
{
thread { print "hello\n" };
print "world";
}
would spawn the first print into a separate thread, and then join before
executing the second print. I would like to see if this can be extended a
bit, using Luke's "object Sigil" proposal:
my $resu
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>
> On Tuesday, May 27, 2003, at 01:16 PM, Austin Hastings wrote:
> > I like and agree with some of what you've been saying. I too think
> that
> > there's a case of "an x is just a y with ..." underlying the whole
> > coro/thread/parallel thing. Tha
On Tuesday, May 27, 2003, at 01:49 PM, Jonathan Scott Duff wrote:
I think there's some timing missing (or maybe it's just me). Executing
a
Code junction implies that I have all of the routines I wish to execute
in parallel available at the same time. This is often not the case.
Or if adding a Cod
On Tuesday, May 27, 2003, at 01:16 PM, Austin Hastings wrote:
I like and agree with some of what you've been saying. I too think that
there's a case of "an x is just a y with ..." underlying the whole
coro/thread/parallel thing. That's why I'm in favor of deconstructing
the threading thing -- a low
On Tue, May 27, 2003 at 01:26:05PM -0700, Michael Lazzaro wrote:
> If you call one routine, piece o' cake, it's not a thread, and it
> doesn't have to do anything fancy. If you call a _junction_ of
> routines, however, _then_ it knows it has to do the extra fluff to make
> them parallel, which
On Tuesday, May 27, 2003, at 12:26 PM, Luke Palmer wrote:
We could also have things like:
sub { ... }
closure { ... }
I think you've finally gone crazy. :-)
All four of these things are closures.
coroutine { ... }
thread{ ... }
Well, yes, I've been crazy for a while no
Michael,
I like and agree with some of what you've been saying. I too think that
there's a case of "an x is just a y with ..." underlying the whole
coro/thread/parallel thing. That's why I'm in favor of deconstructing
the threading thing -- a lower thread overhead means more people can
spawn more
"Michael Lazzaro" <[EMAIL PROTECTED]> wrote > Similarly, then, I
would expect:
>
> sub foo(...) is threaded { ... yield() ... return() }
>
> foo(...args...)
>
> to start &foo as a new thread.
Perhaps we should fall back on the old message passing abstraction, where
messages can be either
> On Monday, May 26, 2003, at 06:51 PM, John Macdonald wrote:
> > This is an interesting idea. I'd add forked processes
> > to the list (which includes the magic opens that fork
> > a child process on the end of a pipeline instead of
> > opening a file.
>
> I thought about that quite a bit, but f
On Monday, May 26, 2003, at 06:51 PM, John Macdonald wrote:
This is an interesting idea. I'd add forked processes
to the list (which includes the magic opens that fork
a child process on the end of a pipeline instead of
opening a file.
I thought about that quite a bit, but fork() is a process-leve
On Monday, May 26, 2003, at 06:10 PM, Dave Whipp wrote:
So, in summary, its good to have a clean abstraction for all the HCCCT
things. But I think it is a mistake to push them too close. Each of
the HCCCT things might be implemented as facades over the underlying
othogonal concepts of data manag
On Monday, May 26, 2003, at 06:10 PM, Dave Whipp wrote:
Michael Lazzaro wrote:
What I'm getting at is that all these concepts are much more related
than they might at first seem, and that the differences between them
are largely of "scope". If we have some form of coroutines, _and_
can run them
37 matches
Mail list logo
