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 read this post far more ti
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
18 matches
Mail list logo
