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 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
"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
