Forum: Ruby-core Fibers as semi-coroutines enabled by default

1018fce89dab3bedcc380fe37d90c9c0?d=identicon&s=25 David Flanagan (Guest)
on 2007-09-26 21:02
(Received via mailing list)
Hi all,

I've been following fibers with interest and just noticed that ko1
modified things so that fibers work as semi-coroutines by default now.
If you just want to use resume and yield, there is no need to require
'fiber'.  (I hope the implication of this is that the JRuby team has
assured ko1 that they will be able to implement Fiber#resume and
Fiber::yield).

To get the full power of co-routines, you need Fiber#transfer and for
that you must still require 'fiber'.  This means, I think, that ko1
judges it unsafe, and I would guess it also means that implemenations
like JRuby may not be able to support it...

Continuations are only supported in 1.9 with require 'continuation'.

Thanks for this change, ko1!

  David

P.S. ext/fiber/fiber.c still contains an external declaration for the
now non-existant function Init_Fiber_body.  The patch below simply
removes it. I suppose a better patch might be to declare the new
function Init_Fiber_as_Coroutine instead.

$ diff -u fiber.c~ fiber.c
--- fiber.c~    2007-09-26 11:31:03.000000000 -0700
+++ fiber.c     2007-09-26 11:44:34.000000000 -0700
@@ -1,6 +1,3 @@
-
-void Init_Fiber_body(void);
-
  void
  Init_fiber(void)
  {
308cbef6e86dfc49cce3b2d4cf42aedc?d=identicon&s=25 SASADA Koichi (Guest)
on 2007-09-27 15:48
(Received via mailing list)
Hi,

David Flanagan wrote:
> like JRuby may not be able to support it...
Thank you for summarise about Fiber.  I think also "Fiber#transfer
is needless/difficult to use".

I'm planning to add something like channel/mailbox to Fiber.   ...
is it overkill?


> P.S. ext/fiber/fiber.c still contains an external declaration for the
> now non-existant function Init_Fiber_body.  The patch below simply
> removes it. I suppose a better patch might be to declare the new
> function Init_Fiber_as_Coroutine instead.

Thank you.  I applied it.
1018fce89dab3bedcc380fe37d90c9c0?d=identicon&s=25 David Flanagan (Guest)
on 2007-09-27 19:28
(Received via mailing list)
SASADA Koichi wrote:
> I'm planning to add something like channel/mailbox to Fiber.   ...
> is it overkill?

That's exciting to hear.  Will you be doing this in time for 1.9.1?

There have been a couple of posts recently about the Actor paradigm
implemented on top of Fiber, but I've never used (nor even really heard
about) this style of concurrency before, so I'm unqualified to answer
your "is it overkill" question.

Is the name "Fiber" settled, or are you still considering changing it?
If fibers are just co-routines, then I'd think a name like "Coroutine"
would be better.  But if fibers are going to be co-routines and actors,
then maybe a vague name like "Fiber" is better because of that
vagueness.

  David
912c61d9da47754de7039f4271334a9f?d=identicon&s=25 Mental Guy (mental)
on 2007-09-27 20:30
(Received via mailing list)
On Thu, 27 Sep 2007 22:47:02 +0900, SASADA Koichi <ko1@atdot.net> wrote:
> I'm planning to add something like channel/mailbox to Fiber.   ...
> is it overkill?

It could be a good idea, as long as you're careful to keep things
simple and follow an established formalism.  I'd personally
recommend the asynchronous pi calculus, which is very simple and
is used in Rubinius core for concurrency.

-mental
308cbef6e86dfc49cce3b2d4cf42aedc?d=identicon&s=25 SASADA Koichi (Guest)
on 2007-09-27 21:21
(Received via mailing list)
Hi,

MenTaLguY wrote:
> On Thu, 27 Sep 2007 22:47:02 +0900, SASADA Koichi <ko1@atdot.net> wrote:
>> I'm planning to add something like channel/mailbox to Fiber.   ...
>> is it overkill?
>
> It could be a good idea, as long as you're careful to keep things
> simple and follow an established formalism.  I'd personally
> recommend the asynchronous pi calculus, which is very simple and
> is used in Rubinius core for concurrency.

I think Fiber/Coroutine should be synchronous.  After all, it's
overkill for simple feature.  This is important that we can make
scheduler, mailbox, asynchronous model framework, etc on user-level
(ruby-level).  Rich features such as mailbox should be implemented
outside Fiber.

Regards,
1018fce89dab3bedcc380fe37d90c9c0?d=identicon&s=25 David Flanagan (Guest)
on 2007-09-27 21:44
(Received via mailing list)
Let me see if I understand: you are NOT introducing any new mechanism
for concurrency into Fiber. But you are considering the addition of some
kind of message queue?

  David
58a68672882676f6bdf817b3c8ff3880?d=identicon&s=25 Tony Arcieri (Guest)
on 2007-09-27 22:04
(Received via mailing list)
On 9/27/07, SASADA Koichi <ko1@atdot.net> wrote:
>
> I'm planning to add something like channel/mailbox to Fiber.   ...
> is it overkill?
>

I think mailboxes can substantially improve the usefulness of Fibers,
especially if you follow the approach of having Fibers automatically
#yield
when their mailbox is empty (or if you have mailbox filters, #yield when
no
messages match the filter)

That's what I was doing here:

http://pastie.caboo.se/97050
912c61d9da47754de7039f4271334a9f?d=identicon&s=25 Mental Guy (mental)
on 2007-09-27 22:17
(Received via mailing list)
On Fri, 28 Sep 2007 04:20:29 +0900, SASADA Koichi <ko1@atdot.net> wrote:
>> It could be a good idea, as long as you're careful to keep things
>> simple and follow an established formalism.  I'd personally
>> recommend the asynchronous pi calculus, which is very simple and
>> is used in Rubinius core for concurrency.
>
> I think Fiber/Coroutine should be synchronous.  After all, it's
> overkill for simple feature.  This is important that we can make
> scheduler, mailbox, asynchronous model framework, etc on user-level
> (ruby-level).  Rich features such as mailbox should be implemented
> outside Fiber.

Channels can be asynchronous even if the implementation of "process"
(fiber) is synchronous.  But a channel implies some kind of
scheduling by definition.  If you don't want scheduling at the fiber,
level, then channels probably don't belong at the fiber level
(Rubinius has them at the thread level).

-mental
Ede2aa10c6462f1d825143879be59e38?d=identicon&s=25 Charles Oliver Nutter (Guest)
on 2007-09-28 04:55
(Received via mailing list)
David Flanagan wrote:
> that you must still require 'fiber'.  This means, I think, that ko1
> judges it unsafe, and I would guess it also means that implemenations
> like JRuby may not be able to support it...

Correct on both counts. Of course, currently Fiber is implemented in
JRuby using a thread, so it's heavier than one would like. It will not
be possible to implement lightweight Fibers or Fiber#transfer without
running a stackless bytecode engine, microthreading JRuby's compiler
output and core class methods, or adding continuations to the JVM. None
of these are likely to happen soon.

- Charlie
This topic is locked and can not be replied to.