Comments on: Fibers & Cooperative Scheduling in Ruby

By: Ruby 1.9.x Concurrency | keyongtech

Ruby 1.9.x Concurrency | keyongtech — Tue, 09 Jun 2009 08:07:27 +0000

[...] in filling in the missing pieces for me, may be helpful if you have the same missing piece :) http://www.igvita.com/2009/05/13/fib…uling-in-ruby/ Regards, [...]

By: William Morgan

William Morgan — Tue, 02 Jun 2009 01:35:30 +0000

There are significant differences between the two. Fibers are non-preemptive threads; continuations are fancy gotos. You can implement fibers with continuations, but there’s no way to implement continuations with fibers. I’ve outlined some of the differences, with examples, here and given an implementation of fibers here. Comments welcome.

By: Ilya Grigorik

Ilya Grigorik — Mon, 01 Jun 2009 22:36:28 +0000

William, I may be misunderstanding your interpretation, but I do think that both concepts are very similar. For example, the semantics around multiple executions of a fiber is limited strictly to the code inside of it - it could exit after one loop, yield, or go back to the top (in which case, it sounds like a generator). Likewise, continuation code can be easily wrapped inside a loop inside to provide similar semantics.

Bottom line is, I think the line between both concepts is so murky in Ruby that I would interpret them as functionally the same (even if there are theoretical differences).

By: William Morgan

William Morgan — Sun, 31 May 2009 20:55:32 +0000

I don’t think continuations and fibers really are the same thing. Please correct me if I’m wrong. A continuation can be captured once, resumed many times, and each time the captured call stack is reinstated, but the heap state is not changed (i.e. it’s shared between successive invocations).

A fiber can be resumed multiple times, but the call stack upon resumption is wherever the fiber last yielded, not where it was originally started. And the heap state is restored for fibers, unlike continuations. And continuations don’t even have a notion of yielding.

It sounds like they may both share a lot of underlying implementation in Ruby 1.9, but the operational semantics are fairly different.

By: Ilya Grigorik

Ilya Grigorik — Sat, 23 May 2009 14:33:34 +0000

Rtaljun, thanks for the catch, updated the link!

By: rtaljun

rtaljun — Sat, 23 May 2009 04:02:42 +0000

Very cool article! I didn’t realize the parallels between continuations and fibers earlier.

The link to “implementation of Futures in Ruby” is broken, I believe?

By: Ilya Grigorik

Ilya Grigorik — Mon, 18 May 2009 22:13:12 +0000

Vidar, you should take a look at mysqlplus gem then!

Xabriel, not sure what you mean by unsafe. The upside of Fibers is that you’re doing your own scheduling.. in which case, yes it is possible that your code never yields. Having said that, that’s your own mistake. ;-)

By: Xabriel

Xabriel — Mon, 18 May 2009 12:04:30 +0000

Correct me if I’m wrong, but isn’t this concept of ‘Fibers’ inherently unsafe? (I.e. What if the Fiber never yields?)

By: Vidar Hokstad

Vidar Hokstad — Mon, 18 May 2009 08:49:28 +0000

Ilya,

Oh, I agree there’s lots of horrible 3rd party extensions, and native gems too…. My pet hate used to be the MySQL lib, which thanks to the braindead C client library just plain couldn’t schedule properly.

By: Fibras: 8 leituras úteis sobre a nova funcionalidade de concorrência do Ruby

Fibras: 8 leituras úteis sobre a nova funcionalidade de concorrência do Ruby — Sun, 17 May 2009 02:42:43 +0000

[...] Fibers & Cooperative Scheduling in Ruby - Ilya Grigorik escreveu talvez a melhor visão geral sobre o assunto. Incluindo um ótimo diagrama, um código de exemplo e uma olhada em como o JRuby e o Rubinius se comparam. Se você só puder ler um artigo, que seja este. [...]