Re: Ruby Fibers (was: threads?)
On Fri, Oct 15, 2010 at 10:22 AM, B. Estrade estr...@gmail.com wrote: Pardon my ignorance, but are continuations the same thing as co-routines, or is it more primitive than that? Continuations are not the same thing as coroutines, although they can be used to implement coroutines - in fact, continuations can be used to implement any sort of flow control whatsoever, because they are a way of generalizing flow control. Goto's, function calls, coroutines, setjmp/longjmp, loops, exception throwing and catching - these and more can all be regarded as special cases of continuation manipulation. A continuation is just a snapshot of a point in a program's run, which can then be 'called' later to return control to that point. The entire execution context is preserved, so you can call the same continuation multiple times, re-enter a function that has already returned, etc. But state changes are not undone, so the program can still behave differently after the continuation is called. -- Mark J. Reed markjr...@gmail.com
Re: Ruby Fibers (was: threads?)
On Fri, Oct 15, 2010 at 09:57:26AM -0400, 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. Pardon my ignorance, but are continuations the same thing as co-routines, or is it more primitive than that? Also, doesn't this really just allow context switching outside of the knowledge of a kernel thread, thus allowing one to implement tasks at the user level? Concurrency can apply to a lot of different things, but the problem is now not only implementing an algorithm concurrently but also using the concurrency available in the hardware efficiently. Brett -- Mark J. Reed markjr...@gmail.com -- B. Estrade estr...@gmail.com
Re: Ruby Fibers (was: threads?)
On Wed, Oct 13, 2010 at 1:20 AM, Tim Bunce tim.bu...@pobox.com wrote: I've not used them, but Ruby 1.9 Fibers (continuations) and the EventMachine Reactor pattern seem interesting. 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.
Re: Ruby Fibers (was: threads?)
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
Re: Ruby Fibers (was: threads?)
On Fri, Oct 15, 2010 at 01:42:06PM +0200, Leon Timmermans wrote:
On Wed, Oct 13, 2010 at 1:20 AM, Tim Bunce tim.bu...@pobox.com wrote:
I've not used them, but Ruby 1.9 Fibers (continuations) and the
EventMachine Reactor pattern seem interesting.
Continuations and fibers are incredibly useful and should be easy to
implement on parrot/rakudo
Forget Parrot, fibers can be implemented in pure Perl 6.
module Fibers;
my @runq;
sub spawn(entry) is export {
push @runq, $( gather entry() );
}
sub yield() is export {
take True;
}
sub scheduler() is export {
while @runq {
my $task = shift @runq;
if $task {
$task.shift;
push @runq, $task;
}
}
}
-sorear
signature.asc
Description: Digital signature
