On Wed, May 28, 2003 at 06:35:31AM -0700, David Storrs wrote:
> On Wed, May 28, 2003 at 04:41:36AM -0600, Luke Palmer wrote:
> > I know it's compile-time binding, but... what's compile-time binding?
> > Luke
>
> Well, perhaps I'm mistaken, but I had understood it to mean simply
> [...]
>
> - Name
--- 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 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 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
"Jonathan Scott Duff" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> > 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
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
--- 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
"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
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
--- 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
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 ;
--- 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
> 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};
> > > traver
"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
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
"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
17 matches
Mail list logo
