On Oct 15, 9:57 am, markjr...@gmail.com ("Mark J. Reed") wrote:
> On Fri, Oct 15, 2010 at 7:42 AM, Leon Timmermans <faw...@gmail.com> wrote:
> > Continuations and fibers are incredibly useful and should be easy to
> > implement on parrot/rakudo but they aren't really concurrency. They're
> > a solution to a different problem.
>
> I would argue that concurrency isn't a problem to solve; it's one form
> of solution to the problem of maximizing efficiency.
> Continuations/fibers and asynchronous event loops are different
> solutions to the same problem.
>
> --
> Mark J. Reed <markjr...@gmail.com>
What prevents perl6 from having both fibers *and* an event loop?
After all, with perl5, you can use Coro and AnyEvent together... they
seem to be a good combo.
Perhaps we don't need threads?
Let's suppose that we provide an easy to use interface to coroutines
(something like Coro, for example), and a native event loop.
Furthermore, suppose that operations which would normally block
(reading from a socket, when there isn't anything ready, for example)
will first label the current coroutine as "not ready" (for the
scheduler's benefit), then start an asynchronous request for the
appropriate type of operation, followed by a call to the scheduler.
The scheduler repeatedly switches to ready coroutines, and calls the
event loop (either with a zero timeout, if there's at least one other
ready coroutine, or an infinite timeout, if there're no ready
coroutines).
When the asynchronous request completes, the event loop puts the first
coro back into a "ready" state, and (from a safe point) calls the
scheduler.
This combination of coroutines and an event loop will provide good
thread-like behavior for io-bound processes, without the complexity
needed for real threads.
For CPU bound tasks, we could just fork, and use IPC to communicate.
The communication overhead will probably be less than the overhead
needed for inter-thread synchronization.
