From: Bill Kelly <billk@...>
Date: 2010-05-19T05:03:10+09:00
Subject: Re: Asynchronous HTTP request

Brian Candler wrote:
> 
> Are you saying that a Fiber will return control to you when it blocks 
> due to lack of data on a socket, as well as when the Fiber explicitly 
> "yields"? What value does it return to you in the blocking case?

As an aside, Fibers can behave in that fashion when used within a
"never block" architecture like EventMachine.

There's also the neverblock library, which employs Fibers similarly:
http://www.espace.com.eg/neverblock


In my case, using a homegrown RPC library with Fibers, on top of
EventMachine, a method call on a 'remote' object suspends the Fiber
until the response is received:

  result = remote_object.fornstaff("dreelsprail")

So, a method call on remote_object explicitly yields (actually,
using Fiber#transfer) behind the scenes so that other fibers may run
in the interim.


It's interesting, so far, as a programming model.  Since there's
only a single thread, there's no need for traditional concurrency
primitives like Mutexes.

On the other hand, reentrancy is still an issue.  So if one is in
the process of modifying the state of an object, one does indeed
need to be aware when a method call might end up yielding the fiber.

...Highlighting the usefulness of approaches where "variables have
the property that they can only be bound/assigned to once" like
the dataflow library mentioned by Tony Arcieri elsewhere in this
thread.


Regards,

Bill