Asynchronicity

Hi all,

Just wondering if anyone can recommend some articles/tutorials on fibers
and async stuff? I’ve had a look around of course, but it always seems
to be the same example of an HTTP server, or some explanation of theory.
Call me an ignoramus (go on, it’s relaxing) but I don’t really care
about the theory, some good examples moving from the simple to the not
so simple in nice gradations would be muy bueno!

If it links in nicely with Eventmachine and/or Thin, all the better.

Regards,
Iain

Good Morning,

On Wed, Jun 8, 2011 at 10:52 AM, Iain B. [email protected]
wrote:

While not a tutorial - EM-Synchrony is an EventMachine/fiber based set
of
classes that are a great example of putting fibers to use. Everything
from
simple sleep and timers using EM/fibers to full blown http clients and
tools
to wrap regular code to run async.

https://github.com/igrigorik/em-synchrony

John

On Wed, Jun 8, 2011 at 11:52 AM, Iain B. [email protected]
wrote:

Hi all,

Just wondering if anyone can recommend some articles/tutorials on fibers and
async stuff? I’ve had a look around of course, but it always
seems to be the same example of an HTTP server, or some explanation of theory.
Call me an ignoramus (go on, it’s relaxing) but I don’t
really care about the theory, some good examples moving from the simple to the
not so simple in nice gradations would be muy bueno!

There isn’t really a lot involved with fibers. Replace that HTTP
request with anything else, and you get the same basic example.

There are some nuances between the use of #transfer and #resume, but
the method count on Fiber is very small, so there isn’t a lot to
learn. Just take one of the examples from one of the existing articles
and experiment a little bit, and you will have the topic well
explored.

There’s nothing extra that needs to happen to link it with
EventMachine, either, since the Fiber API is already so shallow.

1) Create Fiber.

Fiber.new do

# 2) Blah blah blah code that does whatever your code does.

# 3) Grab the current fiber.
f = Fiber.current

# 4) Create some EventMachine protocol object that will do

something for you.
something_doer = EventMachine::Doer.new(stuff).doit

# 5) Setup the callback to wake the fiber up when it's done.
something_doer.callback { f.resume (something_doer) }

# 6) Suspend this fiber so that something else can run.
Fiber.yield

# 7) More blah blah blah that you want to do after your

EventMachine::Doer finishes it’s stuff.

end

If you wrap #3-#6 in a method, then you can call into it via a nice
clean API, treating it just like it were a simple blocking call, and
whatever is doing it need not even know that it is an asynchronous,
nonblocking call. As far as your code, and your thought process while
writing the code is concerned, it will call into the method, and get a
return value from the method. This is the strength of fibers when used
with something like EventMachine, in my opinion. You can make your API
simpler to understand by using fibers to hide the asynchronous nature
of what is happening behind it.

Just work with that basic template, which is what you will find in
most any example, and you should have it figured out pretty quickly.

I have a very simple presentation on this that I did for the
EMRubyConf at RailsConf. I should find out if there is an official
place for these things, but if you want to see it, you can get it
here: http://kirk.swiftcore.org/emrubyconf_fibers_presentation.pdf

Kirk H.
Developer
Engine Y.

Iain B. wrote in post #1004003:

Hi all,

Just wondering if anyone can recommend some articles/tutorials on fibers
and async stuff? I’ve had a look around of course, but it always seems
to be the same example of an HTTP server, or some explanation of theory.

You might want to start by reading up on threads. Then figure out how
fibers are different.

Of course, when reading about threads you might run across an HTTP
example again. That’s because simultaneous execution of two portions of
code is really a myth. What happens is that execution switches rapidly
between the two portions of code giving the appearance that both are
excuting simultaneously–but that is not the case. If neither section
of code has to wait for something–resulting in dead time that the other
section of code can employ to execute its code–then threads do not save
any time. For instance, if you have two threads that do a bunch of
mathematical calculations, then switching rapidly between the threads
until both calculations are finished will take exactly the same time as
executing the entire first calculation and then executing the entire
second calculation(i.e. doing the calculations synchronously).

Enter HTTP. Client code usually has to wait around for a server
response, so sending one request, and then switching to another thread
during the dead time to do something else will speed up execution.

On 8 Jun 2011, at 19:02, John W Higgins wrote:

Good Morning,

I read that and got one of those “I’m speaking to someone on the other
side of the planet, isn’t the internet amazing!” moments :slight_smile:

On 8 Jun 2011, at 20:51, Kirk H. wrote:

There isn’t really a lot involved with fibers.

I hope so! :slight_smile:

I’ve downloaded the pdf, and loaded up the Github, so I’ll take a look
and digest it all over the next couple of days and let you know how I
get on. The first thing I want to use it for is to encrypt photos
uploaded to a server without tying up every instance running.

I really appreciate you both taking the time to answer, thankyou.

Regards,
Iain

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs